On Tue, 15 Sep 2015, Allin Cottrell wrote:
Thanks for Artur for putting this back on the agenda.
I suggest we discuss the issue a bit more fully -- consider the merits of the
proposal and not just the technicalities -- and make a decision.
The proposal is that we move to a version string of the form
<year><sequential release>, the cleanest variant of this being (IMO) 2015a,
As I see it it the pros and cons are roughly as follows:
* Coming up with a version identifier for each release becomes purely
algorithmic: no need (or scope) for discussion.
* Version identifiers become clearly informative. If someone tells you
they're running gretl YYYYx you know immediately how old it is without having
to look up the change log.
* It reflects the fact that gretl development has been for many years a more
or less continuous process. From time to time the changes between versions
have been relatively major (new "genr" implementation, new command
"tokenizer", introduction of GMM, etc.) but to date we have never signalled
that by a change in the "major" version number, which is therefore
uninformative. We've changed the "minor" version from time to time, but
without any clear principle.
True. Let me add: as the project has become more and more stable, releases
have become far less frequent than they used to be (see attached chart).
Something like "2016c" sounds more informative than (say) "1.10.5",
without sounding as funny as "2001q".
* We'd be out of line with most free-software projects, which tend (for
whatever historical reason) to the use the M.N.P versioning idiom.
True, but that's increasingly being called into question, the Linux kernel
being a prime example.
* We would lose the ability to signal a major, backward-incompatible
with a major-version bump. (But it's not clear that we'd ever actually want
to do that.)
I wouldn't rule this out, at some point in the future. But I guess
that with major, backward-incompatible change version numbering would be
the least of our worries!
* It will be a certain amount of bother to make the change, and
want to check that it won't be too bothersome for "downstream" packagers of
gretl for Linux, particularly if we go to <year><letter> (which I prefer)
rather than <year>.<number>.
I guess thet the foremost authority on this would be Dirk (whom I'm
putting in cc).
Personally I quite like the proposal, and I'd be prepared to do
needed to implement it if we decide that way.
It would obviously be easy to retrospectively label all releases to date
using the proposed scheme (e.g. in the change log, where we should keep the
old version IDs too, for reference). And as Sven has said, we could easily
translate the proposed idiom to a single integer that preserves order. At
present we have
$version = 10000*M + 1000*N + P
so 1.10.2 -> 11002
Just say our next release were "2015d": in that case we could
$version = 10*year + alpha_order(letter)
so 2015d -> 20154
(This would get messed up if there were more than 9 releases in a given year,
but I think we can rule that out.)
Alternativey, we could use the convention
$version = 1000*(year-2000) + alpha_order(letter)
so 2015d becomes 15004 but 2015k (if ever necessary) would be 15011.
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)