Re: API Change - tidyReleaseDate()

On 11/02/2015, at 2:57 pm, Jim Derry <[email protected]> wrote:
> > Especially when your build tools should give you accurate release =
dates for free!
>=20
> 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.
>=20
> 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 =3D=3D 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.