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?

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 confusing. 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).