9:06 a.m.
Hi guys,
Real brief, am conference traveling over in London, ...
On 15 September 2015 at 20:42, Riccardo (Jack) Lucchetti wrote:
| On Tue, 15 Sep 2015, Allin Cottrell wrote:
|
| > 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.
|
| 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".
|
| > 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.
|
| 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 change
| > 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 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>.
|
| 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 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
That is being used elsewhere ... but only internally. Here is what our Rcpp
does:
#define Rcpp_Version(v,p,s) (((v) * 65536) + ((p) * 256) + (s))
#define RcppDevVersion(maj, min, rev, dev) (((maj)*1000000) + ((min)*10000) +
((rev)*100) + (dev))
// the currently released version
#define RCPP_VERSION Rcpp_Version(0,12,1)
// the current source snapshot
#define RCPP_DEV_VERSION RcppDevVersion(0,12,1,0)
But version 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.
| > 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.)
|
| 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.
I find that mostly unreadable and would use it at most internally.
Cheers, Dirk
|
| -------------------------------------------------------
| Riccardo (Jack) Lucchetti
| Dipartimento di Scienze Economiche e Sociali (DiSES)
|
| Università Politecnica delle Marche
| (formerly known as Università di Ancona)
|
| r.lucchetti(a)univpm.it
| http://www2.econ.univpm.it/servizi/hpp/lucchetti
| -------------------------------------------------------
| [DELETED ATTACHMENT releases.png, PNG image]
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd(a)debian.org