Beyond 2.8 - version numbering

[Geert Janssens]

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.


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 ?

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

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.

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

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

Geert