Beyond 2.8 - version numbering

Adrien Monteleone adrien.monteleone at
Wed Jan 10 13:37:30 EST 2018

> On Jan 10, 2018, at 11:00 AM, Geert Janssens <geert.gnucash at> wrote:
> Op donderdag 4 januari 2018 00:23:57 CET schreef Frank H. Ellenberger:
>> Am 03.01.2018 um 17:41 schrieb Derek Atkins:
>>> 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.
>> +1
> How is the upgrade to gtk3 (from gtk3, so a fundamental version change) 
> important in the decision to make a fundamental version change for gnucash as 
> well ?
> We didn't do so when we started to support guile 2 for example, nor when we 
> changed from aqbanking 4 to aqbanking 5.
> Your reply also alludes we should follow Gtk's fundamental numbering as 
> gnucash has done in the past as well.
> However I currently see several reasons *not* to continue that scheme. In no 
> particular order:
> * The currently active developers plan to replace gtk eventually. This is 
> still far away and conceptual, but if it does happen gtk's numbering wouldn't 
> make sense.
> * Gtk itself has recently decided to change its numbering policy. The project 
> has decided to release incompatible changes every two years, in effect 
> updating the fundamental number at the same pace. Our release cycle is much 
> slower than that (typically 3-4 years). So our release numbers will start 
> falling behind on gtk's after some time. So it would mean in the best case 
> we'd go from 3.0.x to 4.0.x if we try to keep up with gtk, or in the worst 
> case from 3.2.x to 5.0.x if we decide to skip a gtk release. In the first case 
> the middle number would never be used any more, in the latter we'd get 
> unexpected version jumps. I think we all agree that latter is not an option.

I should think that the major version jump does not necessarily need to be the same exact specific gtk number. It just needs to increment. So if you skipped gtk3 and opted to work straight on moving to gtk4, then your next major version would still be 3.0. If you make 3.0 now in the move to gtk3, and you skip on to gtk5 because of the differences in Gnome’s and GnuCash's development schedules, that GnuCash major version would be 4.0. It’s the next version because it is a fundamental change, but I don’t think the guideline means you have to be tied to someone else’s actual number or else every app following that scheme would use the same version numbers as gtk. That might work fine for the Gnome desktop and Gnome applications that are released as part of the desktop environment by Gnome developers, but I don’t see that it makes sense for outside projects, and certainly not cross platform apps.

Would you switch numbering schemes entirely if you switched to Qt? I suppose until GnuCash adopts an MVC approach, incrementing the major version with gtk (or Qt) changes has merit, but I would think the ‘cleaner’ approach would be to have your own versioning scheme independent of platform, toolkits, or even underlying language.

> We clearly all agree the jump to 3.0 is in order. Personally however I'd not 
> do it because the version of gtk we now depend on is also 3.x.
> Perhaps that's not what you meant to imply. In which case the above is just a 
> confirmation of why we shouldn't from my point of view.
>>> 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.
>> +1
> So this indirectly advocates to keep a distinction between fundamental changes 
> and major changes. What criteria make this distinction in a way that's 
> relevant enough to a maintainer and - even more importantly - an end user to 
> do so ?

I would think file incompatibility is a clear distinction. But if that’s not the case, the developers will have to come up with their own guidelines. Rebasing major portions of the code (as you are currently doing) might be just such a reason.

Personally, I’d be confused as a user if an update was only a bug fix and the minor number changed. I’d expect to see new features as well in that case. That may be simply a matter of habit, though since that usage is so pervasive, I’m sure I’m not the only one with such expectations.

>> Maintainers might have a policy to update bugfixes in their current
>> release, mayor changes in the next release and for fundamental changes
>> both versions.
> I understand "bugfixes in their current release" and "major changes in the 
> next release", but I don't understand what you tried to convey with "and for 
> fundamental changes both versions". Can you explain it ?
> I will assume with "maintainer" you are mostly referring to distro packagers 
> and similar, people that take our sources and offer it in a larger context.
> I understand these people need information to decide whether a new release can 
> be considered maintenance or not. I don't see why this can't be conveyed with 
> 2 numbers. And for that I'm particularly looking at our current development 
> model. We don't use 3 levels. We only use 2: a master branch (new development) 
> and maint (bugfixes and possibly small feature improvements).
> Since we only maintain two development levels ourselves, keeping 3 levels in 
> the version number doesn't help maintainers in any useful way regardless of 
> the theory behind the numbering model.
>> The 3 levels also should give admins and users a clue how much time is
>> needed for
>> dependency changes and
>> understanding new concepts.
> I have the same reflection here. We only use two levels in practice. So 
> keeping the third level is only artificial.
> What I'm trying to convey is that I believe the numbering system we choose 
> should be consistent with our development model.
> A numbering system featuring a "fundamental" change suggests the project using 
> it does actually make "fundamental" changes reasonably frequently.
> That's simply not the gnucash way. We're a small team adopting an incremental 
> development model. So I don't expect many fundamental changes at all. Take the 
> C++ conversion for example. If we'd have implemented all of that in one single 
> development cycle (which at the current pace would have taken at least 3 times 
> more time than we spent on it so far), that would have been a fundamental 
> change IMO. But we chose to do it gradually, spread over several major 
> releases to come.

I’m still getting my feet wet learning GnuCash code, and haven’t made any commits, so I wasn’t going to chime in at all on this topic, but what you describe here was the first thing I thought of when you opened the thread. If the development approach is more incremental and less major-all-at-once release then why not move to a date based versioning system?

This would solve the problem of looking stale to users, and still increment each release number in a meaningful way. Since you don’t hold back major changes such as the move to c++ or the jumps to gtk3 as an ‘all-at-once’ update, I don’t see how the present scheme is really meaningful even to developers. One can’t say that 3.0 was the full port to gtk3, (if some of it happened in the 2.x cycle) or that the rebase to c++ was the defining change. (since definitely this has been on-going in the 2.x cycle)
> Do the new looks of gtk3 qualify sufficiently as a fundamental change ? I 
> don't think so personally. We have gone out of our way to keep everything as 
> close as possible as it was in the previous release. That it looks differently 
> is not our choice, but rather the gtk design team's choice. If we could avoid 
> it I would have done so.
> For changes in the past that would have qualified, adding a database backend 
> might have been considered a fundamental change. Yet even then we didn't 
> change the fundamental number. Why not ? Because the old way with xml 
> continued to work just fine and was even preferred.
> Semantic versioning on the other hand suggests the left most number should be 
> reserved for incompatible changes, which I find a much more useful definition. 
> And we make incompatible changes with every major release for which we 
> currently update the second number instead of the first one. So our version 
> would convey much more information if we did follow that and make the next 
> major series after the 3.0 series 4.0, rather than 3.1/3.2.

If you’re making incompatible changes and not updating the first number, nothing can fix that except re—numbering the releases or figuring what it should be now and jump accordingly, then keep up after that.

> Semantic versioning proposes an in between number for backwards compatible new 
> features. We don't have that intermediate level. Depending on the complexity 
> and size we decide to add a new feature to the next major version or in the 
> next bugfix release. (Note the new gtk versioning semantics do follow this 
> pattern more closely and they do use the 3 numbers in this semantic way from 
> now on as far as I understand).

So new features appear in bugfix releases without changing the minor number? (the ‘y’ in x.y.z)

It seems to me the problem isn’t so much what scheme to follow but that there really isn’t one being followed. If a new feature was introduced in 2.6.19 that didn’t exist in 2.6.18 then why didn’t the version change to 2.7.0? (or 2.8.0 if you’re using odd minors for testing)

If you are introducing new features every ‘z’ release to the point the numbers would get silly, then that tells me the case for a date based system is quite strong.

> So in my opinion either we update our development model and start maintaining 
> a separate "compatible features" branch and do reqular releases from that one 
> next to bugfix releases from the "maint" branch or we adjust or numbering 
> system to match how we develop. I think this makes things more clear.
> Note that adding a third branch does imply additional release manager overhead 
> which I would personally like to avoid given our small team.
> And my last motivation to update our numbering system is subjective user 
> perception. Gnucash is targeted at normal computer users, not developers 
> (we're not a library, but an end user application).
> With our current development cycle, our fundamental number increases only once 
> a decade or so (to illustrate 2.0 was released in 2006 --  almost 12 years 
> ago).
> In the current age of internet speeds this risks being perceived as stagnating 
> development. Consider even gtk (our current "reference") is aiming to increase 
> the fundamental number every 2 years!
> I would hope that updating the fundamental number every 3-4 years (in our 
> current development model) can help keeping the gnucash image more fresh. I'll 
> grant this is just a tiny aspect of user perception, but an easy one to 
> implement…

A date based system would solve this perception as noted. But you could still use semantic versioning for the component parts. If those have enough separation, it might even be more meaningful to the developers. In an MVC scheme, the View components might have their own version cadence based on gtk or whatever toolkit you use, the Model components their own, and the Controller components their own, but the whole package might have a version of say 18.03.1, 18.06.4 etc. (with ‘x’ being the year, ‘y’ being the month, and ‘z’ being the incremental bug fix release—or however you choose to display the number, some use only a year version and a more detailed number after a ‘-‘)
>>> I'm fine with dropping the even/odd and just jumping t0 3.0.80 (or 90)
>>> for testing pre-releases.
>> The rule is simple: Do not install the odd version on productive systems!
> The other rule is equally simple: don't install the .9xx version on production 
> systems.
> More specifically, where did this even/odd rule come from ? It looks like a 
> gnome-ism, not a more universal standard. For example the kde ecosystem 
> doesn't follow it, nor do several big applications such as libreoffice or 
> firefox, both gtk based applications.
I don’t care for the odd/even scheme either. But would using .9xx create any issues if there is a x.y.9 bugfix release? Does x.y.900 or x.y.901 precede x.y.1? Does the .9xx increment only after a regular release or might it increment without releasing a regular ‘z’ bugfix? (such as moving from .900 to .901 then .902 without releasing x.y.1 in between)

I think an ‘a/b/r’ or 'alpha/beta/rc' designation is quite easy for testers and users to follow and comprehend. That system also doesn’t require the ‘burning' of any numbers.

If any of my comments here are out of place, my apologies.


> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list