Re: [Gretl-devel] versioning

Thanks for Artur for putting this back on the agenda. http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005937.html 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, 2015b, ... As I see it it the pros and cons are roughly as follows: Pro: * 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.

Con: * 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.

* We would lose the ability to signal a major, backward-incompatible change with a major-version bump. (But it's not clear that we'd ever actually want to do that.)

* It will be a certain amount of bother to make the change, and we'd probably 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>.

Personally I quite like the proposal, and I'd be prepared to do the work 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 define $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.)