Re: API Change - tidyReleaseDate()

On 11/02/2015, at 2:57 pm, Jim Derry <balthisar@gmail.com> wrote:
> > 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 is perfectly meaningful.  The whole point I am making is that "release date" and "semantic version"
tell you DIFFERENT things about a program.  It is true that "release date" is an inferior substitute
for "semantic version", just like pepper is an inferior substitute for salt.  As it happens, I never
use pepper, but I wouldn't get away with taking it off the table just because I'd put salt there.

It is also the case that "build date" is not the same as "release date".
If you take an old version and patch it, you have a new release with a new release date.
It also has a new build date.
If you take an old version and DON'T patch it, you have an old release with an old release date.
Recompiling it will give you a new build date, but that's not the same as release date.
> 
> I would still argue for the semantic version number in addition to the release date.

Of course.  That's my whole point.  They are (correlated but logically) independent
pieces of information about a program.  It is good to have *both*.

> 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!)

According to semver.org, in 5.0.1
 - the MAJOR version (5) changes when there are incompatible API changes
 - the MINOR version (0) changes when you add stuff in a compatible way
 - the PATCH version (1) changes when you make "backwards-compatible bug fixes".
Of course, it's not entirely clear what "backwards-compatible bug fixes" are.
If I take a square root function that raises an exception for -0.0 and modify
it to return -0.0 as the IEEE floating point standard requires (that is, so
that when x == 0, sqrt(x) is identical to x), I would normally think of that
as a backwards-compatible bug fix.  If a security hole is closed, I would
normally think of that as a backwards compatible bug fix, and I would like to
see those systems upgraded.

I suppose whether a bug fix counts as backwards-compatible depends on how
strong a specification you have in the interface.  If your specification says
"sqrt(x) raises an exception if x has the sign bit set", then the change about
is not backwards compatible.  If your specifications says "sqrt(x) raises an
exception if x < 0", then the change might count as backwards-compatible.

Here's one way in which a date can be useful and a semantic version not so:
suppose a new security hole is announced, like Heartbleed or POODLE.  If I
know a program was released after the hole was introduced but before it was
closed, it's worth taking some time to find out if there is a new version.
The semantic version number gives me no clue here.  (Actually, this is one
reason why I dislike dynamic linking.  The program may have been perfectly
secure when released, but an update to a library it depends on may have
introduced a security hole.)

I don't think we have a good answer to versioning yet.  Semantic versioning
tries to answer the question "if I wrote for version X and switch to version
Y, is it likely to break".  But of course typical programs these days have
lots of components, some third-party, some dynamically bound, and each of
them has its own version and release information and its own vulnerabilities
and history.  We can hardly fit everything that might be useful into a single
'version number'.

I once did some work on a program where a potential customer had a rigid
policy that _every_ program they bought had to provide its version number
and release date.

Received on Wednesday, 11 February 2015 03:29:31 UTC