Re: API Change - tidyReleaseDate()

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 <balthisar@gmail.com> 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.
>
>
>