Beyond 2.8 - some design thoughts

Geert Janssens geert.gnucash at kobaltwit.be
Fri Dec 29 13:03:52 EST 2017


Op vrijdag 29 december 2017 18:23:57 CET schreef John Ralls:
> > On Dec 29, 2017, at 8:20 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op vrijdag 29 december 2017 10:11:08 CET schreef Alen Siljak:
> >> I'd like to add that, to me, the difference between stable and unstable
> >> version is obvious enough if I see v2.8.0-alpha1, 2.8.0-alpha2,
> >> 2.8.0-beta1, 2.8.0-rc1, and then 2.8.0. I see no need for separate
> >> version
> >> numbers.
> > 
> > That's a good point. I should check though whether our build system can
> > handle this. If it does or if we can make it so, using explicit
> > alpha/beta/rc strings would be very clear. It would be also require some
> > getting used to as until now we never made an explicit distinction
> > between alpha/beta/rc (though we imply it sometimes in warnings). Should
> > we ? And if so, what would be the criterion ?
> 
> I don’t think that the distros would like that scheme. They want suffixes
> separated by a hyphen to be reserved for their own nefarious purposes
> (mostly designating releases with back ported patches from the project’s
> VCS).
> 
> Better, I think, to use x.9y or perhaps x.9yy for unstable releases.
> 
> Regards,
> John Ralls

Fair point too. Keeps our changes to the build system smaller as well.

I believe 10 unstable releases may be a tad sharp (we had 11 for the 2.5 
series). So let's go for the x.9yy scheme instead.

To summarize:

1. our new version scheme will have two numbers x.y

2. The x number will increase for releases with backwards incompatible changes 
(which we typically call major releases)

3. The y number increases for releases with bugfixes or backwards compatible 
improvements (which we typically call bugfix releases)

4. Whenever the x number increases, the y number is reset to 0

5. Major releases are usually preceded by a number of unstable releases to 
allow wider testing and give translators time to translate new and changed 
strings in the upcoming major release. These unstable releases will be 
numbered x.9zz (so the second number can range from 900 to 999).

I believe that is what most have roughly agreed to (or at least have no strong 
objections against).

John also suggested we can skip 2.8.0 and go straight for 3.0. I'm liking that 
idea more and more. It's indeed consistent with the gnome guidelines and 
allows us to start using the new scheme already now.

Any more closing comments before we officially adopt this new scheme ?

Regards,

Geert


More information about the gnucash-devel mailing list