Re: API Change - tidyReleaseDate()

--===============1133953851391666878==
Content-Type: multipart/alternative; boundary=047d7bb70a44cd34c2050ec6521a

--047d7bb70a44cd34c2050ec6521a
Content-Type: text/plain; charset=UTF-8

> 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.

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

<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 answe=
rs.</span><div><span style=3D"font-size:12.8000001907349px"><br></span></di=
v><div><span style=3D"font-size:12.8000001907349px">That&#39;s a good point=
. The thought was that providing NO answer might break existing functionali=
ty in an application that doesn&#39;t check that the date is formatted in t=
he same way every time, thus using the Unix epoch to represent &quot;no ans=
wer&quot; without breaking an API. If not for this concern we might have si=
mply made the date function a synonym of the version function.</span></div>=
<div><span style=3D"font-size:12.8000001907349px"><br></span></div><div><sp=
an style=3D"font-size:12.8000001907349px">&gt;=C2=A0</span><span style=3D"f=
ont-size:12.8000001907349px">Especially when your build tools should give y=
ou accurate release dates for free!</span></div><div><span style=3D"font-si=
ze:12.8000001907349px"><br></span></div><div><span style=3D"font-size:12.80=
00001907349px">Our build tools are currently capable of giving us a build d=
ate 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&=
#39;t meaningful.</span></div><div><span style=3D"font-size:12.800000190734=
9px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">It&=
#39;s trivial to update the build date at the same time as the version numb=
er so that the previous paragraph doesn&#39;t apply, which would be the pre=
ferred approach if we decide not to deprecate `tidyReleaseDate()`. That is,=
 it becomes a true &quot;release&quot; data and not a &quot;build date&quot=
; (as it was using some of the legacy build systems).</span></div><div><spa=
n style=3D"font-size:12.8000001907349px"><br></span></div><div><span style=
=3D"font-size:12.8000001907349px">I would still argue for the semantic vers=
ion number in addition to the release date. Do I want the sysadmin to upgra=
de 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 _onl=
y_ a date might mean that there&#39;s a two year difference between 5.0.0 a=
nd 5.0.1. (Hopefully this situation doesn&#39;t come to pass again!)</span>=
</div><div><span style=3D"font-size:12.8000001907349px"><br></span></div><d=
iv><span style=3D"font-size:12.8000001907349px">So the current tally stands=
 as:</span></div><div><span style=3D"font-size:12.8000001907349px"><br></sp=
an></div><div><span style=3D"font-size:12.8000001907349px">1 in favor of ke=
eping both.</span></div><div><span style=3D"font-size:12.8000001907349px">0=
 other responses.</span></div><div><span style=3D"font-size:12.800000190734=
9px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">Ric=
hard, thanks for the feedback.=C2=A0</span></div><div><span style=3D"font-s=
ize:12.8000001907349px"><br></span></div><div><span style=3D"font-size:12.8=
000001907349px"><br></span></div></div>

--047d7bb70a44cd34c2050ec6521a--


--===============1133953851391666878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--===============1133953851391666878==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tidy-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tidy-develop

--===============1133953851391666878==--