Beyond 2.8 - some design thoughts

Derek Atkins warlord at MIT.EDU
Wed Jan 3 11:41:24 EST 2018

John Ralls <jralls at> writes:

>> 2. Versioning.
>> We currently use a version scheme gigantic.major.minor[-build]. Like 2.6.19 
>> (and an optional -2 if we had to release more than once to get it right). For 
>> the 3 levels we really only use two. The 2 in front has been updated when 
>> gnucash migrated from gtk to gtk2.  We will migrate to gtk3 for gnucash 2.8 
>> yet we don't changed to 3.0 as a result. The migration to gtk2 has
>> been a long
>> time ago and the software world has evolved since then. Release cycles in 
>> general have shortened. Incremental changes are usually preferred over big 
>> bang changes. So I think our numbering scheme is in for a modernization.
>> Here's my proposal:
>> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
>> build] instead. 
>> Major releases would increment the first number. Bugfix releases the second.
>> So after 2.8 the next major release would be 3.0, bugfix releases for that 
>> major release would become 3.1, 3.2, 3.4...
>> I would drop the idea of odd numbers being development snapshots and even 
>> numbers being stable ones. Instead I see several options, I haven't decided 
>> which one is most elegant/kludgy:
>> Option A: let's number development snapshots starting from
>> x.90. That gives us
>> 10 development snapshots. If that's not enough we can either choose
>> to start a
>> bit earlier, like x.80 or from x.98 jump to x.980 to give us 20 more.
>> Option B: as a variation all development snapshots do use a 3 number version: 
>> x.99.z with 99 clearly indicating "right before the next major release" and z 
>> incrementing with each snapshot.
>> This makes development snapshots slightly more verbose in their numbering but 
>> gives us cleanly incrementing stable releases. The latter are more visible to 
>> most users, so I personally care more about those.
>> The development snapshots between 2.8 and 3.0 fall a bit in between. We could 
>> choose to handle them old style or new style as we see fit. Old style would 
>> mean we'd still work with a 2.9.x series. New style would mean we'd
>> start with
>> 2.8.90/ as we see fit.
>> Thoughts ?
> I’m indifferent to the versioning system as long as it’s consistent,
> but the distro packagers aren’t. Some of them recite the “Semantic
> Versioning” [1] mantra even though it really applies only to
> libraries.
> Back when we released 2.6 we were unsure about whether the coming
> version would be 2.8 or 3.0. One of the criteria proposed was that we
> should call it 3.0 if we upgraded to Gtk+3. Well, we have, so maybe
> the coming release should be 3.0.0 instead of 2.8.0. That would
> certainly be consistent with the Gnome guidelines [2] that include a
> major change in the GUI as a reason for bumping the major version.
> Should some of the component libraries (especially libgnucash) have
> separate versioning that follows the semantic versioning rules?

I see no reason that we can't jump from 2.7.x to 3.0[.0] when we release.
And since we DID upgrade to GTK3, I think we should do that.

As for whether to drop the third entry is less important to me, but I
still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
leave 3.1/3.2 for more major changes.

I'm fine with dropping the even/odd and just jumping t0 3.0.80 (or 90)
for testing pre-releases.

> Regards,
> John Ralls


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list