Re: API Change - tidyReleaseDate()

--089e0103e4ce825db0050ec6ba85
Content-Type: text/plain; charset=UTF-8

Deprecating the release date is fine by me, however, I do agree with
Richard in that the current API should return an accurate date until it's
fully removed from the API. Since there's already concerns brought up on it
and it's trivial to keep updated we might has well let it tag along with
the new semantic versioning.



On Tue Feb 10 2015 at 8:57:50 PM Jim Derry <[email protected]> wrote:

> > One thing I will say is that wrong answers are, as a rule, WORSE than
> no answers.
>
> That's a good point. The thought was that providing NO answer might break
> existing functionality in an application that doesn't check that the date
> is formatted in the same way every time, thus using the Unix epoch to
> represent "no answer" without breaking an API. If not for this concern we
> might have simply made the date function a synonym of the version function.
>
> > Especially when your build tools should give you accurate release dates
> for free!
>
> Our build tools are currently capable of giving us a build date right now,
> which means we could have a version 6.0.0 built in 2015 that would appear
> newer than a 7.1.2 built in 2014, and so in an of itself isn't meaningful.
>
> It's trivial to update the build date at the same time as the version
> number so that the previous paragraph doesn't apply, which would be the
> preferred approach if we decide not to deprecate `tidyReleaseDate()`. That
> is, it becomes a true "release" data and not a "build date" (as it was
> using some of the legacy build systems).
>
> I would still argue for the semantic version number in addition to the
> release date. Do I want the sysadmin to upgrade 25 systems when the version
> moves from 5.0.0 to 5.0.1? What about to 5.1.0? That implies an API change
> I have to test for first. Whereas using _only_ a date might mean that
> there's a two year difference between 5.0.0 and 5.0.1. (Hopefully this
> situation doesn't come to pass again!)
>
> So the current tally stands as:
>
> 1 in favor of keeping both.
> 0 other responses.
>
> Richard, thanks for the feedback.
>
>
>

--089e0103e4ce825db0050ec6ba85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Deprecating the release date is fine by me, however, I do =
agree with Richard in that the current API should return an accurate date u=
ntil it&#39;s fully removed from the API. Since there&#39;s already concern=
s brought up on it and it&#39;s trivial to keep updated we might has well l=
et it tag along with the new semantic versioning.<div><div><br></div><div><=
br></div></div></div><br><div class=3D"gmail_quote">On Tue Feb 10 2015 at 8=
:57:50 PM Jim Derry &lt;<a href=3D"mailto:[email protected]">balthisar@gm=
ail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&=
gt;=C2=A0<span style=3D"font-size:12.8000001907349px">One thing I will say =
is that wrong answers are, as a rule, WORSE than no answers.</span><div><sp=
an style=3D"font-size:12.8000001907349px"><br></span></div></div><div dir=
=3D"ltr"><div><span style=3D"font-size:12.8000001907349px">That&#39;s a goo=
d point. The thought was that providing NO answer might break existing func=
tionality in an application that doesn&#39;t check that the date is formatt=
ed in the same way every time, thus using the Unix epoch to represent &quot=
;no answer&quot; without breaking an API. If not for this concern we might =
have simply made the date function a synonym of the version function.</span=
></div></div><div dir=3D"ltr"><div><span style=3D"font-size:12.800000190734=
9px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">&gt=
;=C2=A0</span><span style=3D"font-size:12.8000001907349px">Especially when =
your build tools should give you accurate release dates for free!</span></d=
iv><div><span style=3D"font-size:12.8000001907349px"><br></span></div></div=
><div dir=3D"ltr"><div><span style=3D"font-size:12.8000001907349px">Our bui=
ld tools are currently capable of giving us a build date right now, which m=
eans we could have a version 6.0.0 built in 2015 that would appear newer th=
an a 7.1.2 built in 2014, and so in an of itself isn&#39;t meaningful.</spa=
n></div><div><span style=3D"font-size:12.8000001907349px"><br></span></div>=
<div><span style=3D"font-size:12.8000001907349px">It&#39;s trivial to updat=
e the build date at the same time as the version number so that the previou=
s paragraph doesn&#39;t apply, which would be the preferred approach if we =
decide not to deprecate `tidyReleaseDate()`. That is, it becomes a true &qu=
ot;release&quot; data and not a &quot;build date&quot; (as it was using som=
e of the legacy build systems).</span></div><div><span style=3D"font-size:1=
2.8000001907349px"><br></span></div><div><span style=3D"font-size:12.800000=
1907349px">I would still argue for the semantic version number in addition =
to the release date. Do I want the sysadmin to upgrade 25 systems when the =
version moves from 5.0.0 to 5.0.1? What about to 5.1.0? That implies an API=
 change I have to test for first. Whereas using _only_ a date might mean th=
at there&#39;s a two year difference between 5.0.0 and 5.0.1. (Hopefully th=
is situation doesn&#39;t come to pass again!)</span></div><div><span style=
=3D"font-size:12.8000001907349px"><br></span></div><div><span style=3D"font=
-size:12.8000001907349px">So the current tally stands as:</span></div><div>=
<span style=3D"font-size:12.8000001907349px"><br></span></div><div><span st=
yle=3D"font-size:12.8000001907349px">1 in favor of keeping both.</span></di=
v><div><span style=3D"font-size:12.8000001907349px">0 other responses.</spa=
n></div><div><span style=3D"font-size:12.8000001907349px"><br></span></div>=
<div><span style=3D"font-size:12.8000001907349px">Richard, thanks for the f=
eedback.=C2=A0</span></div><div><span style=3D"font-size:12.8000001907349px=
"><br></span></div><div><span style=3D"font-size:12.8000001907349px"><br></=
span></div></div>
</blockquote></div>

--089e0103e4ce825db0050ec6ba85--