Re: [Gretl-devel] versioning
On Wed, 16 Sep 2015, Dirk Eddelbuettel wrote:
[...]
[V]ersion numbers are for humans first. I urge you to reconsider and
do something like
2015.09-n
as eg ESS (Emacs mode for R) does. Or just keep with 1.2.3 -- I
would counter the "it is under attack". Google 'semantic
versioning', it is very much alive and used. I still prefer it.
On semantic versioning, see http://semver.org , where this approach is
defined and advocated. I think this makes a lot of sense for libraries
upon which other software is dependent. Now in fact we have been "sort
of" using semantic versioning for the libgretl library for some time.
The current libgretl is
libgretl-1.0.so.14.0.0
(MAJOR=14, MINOR and PATCH=0). What we've done for the last several
releases is increase the MAJOR number each time, leaving MINOR and
PATCH at zero. This reflects the fact that (almost) every release has
brought some backward-incompatible change in the libgretl API. That in
turn reflects the fact that, as a practical matter, we don't have to
worry much about maintaining API compatibility since, to our
knowledge, there's no other public free software project that depends
on libgretl. (And we've never released the programs and the library
independently, but always as a package.)
I think we could maintain SemVer for the gretl library (and apply it
more rigorously[*]) while switching to <year><letter> for gretl the
program. It seems to me that SemVer doesn't really apply to end-user
programs (nor to the Linux kernel, as Jack mentioned). What we've done
to date with the gretl X.Y.Z version numbers sorta looks like semantic
versioning but the resemblance is superficial, and the numbers are
not meaningful to users -- and as Dirk says, "version numbers are for
humans first."
[*] For example, in the 1.10.1 release we just fixed a bug, so if we
were following SemVer accurately the library version should have gone
from 12.0.0 to 12.0.1, not 13.0.0.
Allin