Re: API Change - tidyReleaseDate()

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