Beyond 2.8 - some design thoughts

Sumit Bhardwaj bhardwajs at gmail.com
Fri Dec 29 13:12:59 EST 2017


Geert,

How would this impact the branching? Would we still have master, unstable,
and maint? And, how would those correspond to the release versions?

Thanks,
Sumit

On Fri, Dec 29, 2017 at 10:03 AM, Geert Janssens <geert.gnucash at kobaltwit.be
> wrote:

> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list