On Mon, 14 Sep 2015, Sven Schreiber wrote:
Am 14.09.2015 um 15:17 schrieb Riccardo (Jack) Lucchetti:
> On Fri, 11 Sep 2015, Artur Tarassow wrote:
>> Dear all,
>> I just remembered the discussion we had in Berlin about the upcoming
>> versioning of gretl.
>> I really, and I think I wasn't alone with this, liked idea to version
>> it using years as e.g. Matlab does (Gretl2015a). This may underline
>> the ongoing development of gretl.
>> Is this still on the table?
> I agree, with one proviso: we already have the $version accessor, which
> is geared towards the xx.yy.zz scheme. I don't think it would be a wise
> idea to break that.
> Hence, I guess that the best thing will be to market future versions
> with the year-letter convention, but to keep the old numbering scheme
> internally. So, for example, assuming that we release the next version
> in February 2016, we'll announce it as Gretl 2016a (or perhaps, simply
> Gretl 2016), but $version will be equal to 11003 or something like that.
As I had already mumbled quietly at the conference, I don't understand the
problem with switching the version numbers to years. In terms of the $version
accessor, the major number would undergo a massive jump from 1 to 2015, yes,
but so what? As 2015 > 1 there is no rupture for determining minimum version
requirements. The minor and micro numbers could well stay like they are. So
the next release (hopefully before 2016) would be something like 2015.2.0 or
2015.2.1. You could even mimick Ubuntu if you like and make the second-level
number the month, in case you're worried that otherwise it would be
If you want, you could also say that the 3rd-level (micro) number change is
only for bugfixing, and new functionality or incompatible changes would only
happen at 2nd-level changes. But that's a different issue really, no need to
mix that into this discussion, actually.
Or to make it clear, I guess I'm strongly against having different numbers
for external and internal purposes. This would just create confustion and
deter people from active collaboration (package writing for example).
As folks may have noticed, I stuck with the old-style 1.10.2 for
yesterday's release. A fair number of source files (including server
sources and website template files) would have to be modified to
handle new-style versioning.
Since Artur mentioned Matlab, I might point out that Matlab has both
X.Y "versions" (currently 8.6) and RYYYYx "release names" (R2015b).
Not sure we'd want to emulate that.
I think that if we do go over to year + modifier, the modifier should
be just a single letter or digit in simple sequence by release
(a,b,... or 1,2,...), with an infix dot if a digit. If we use a digit
it ought to be possible to make the numbering follow on from the
current system (with a gap, of course). Year plus letter a la Matlab
gives a clearer signal to the user but would be more trouble to
dovetail with current practice.