Beyond 2.8 - version numbering

[Geert Janssens]

Op woensdag 10 januari 2018 19:37:30 CET schreef Adrien Monteleone:
> 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.

Yes, that's my view on this as well.

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

The more I read such remarks the more I'm convinced our current version 
mechanism is wrong :-)
We change our minor number changes (I presume you are referring to the middle 
number in semantic versioning), each time we release a version of gnucash that 
can have *incompatible* changes, in addition to new features. Whenever the 
micro version changes (the last number), that can mean bugfixes *and* small 
new (compatible) features. So you're already making wrong conclusions based on 
our version numbers.

People keep referring to the distinction between bugfixes, new features and 
"major changes (typically incompatible)". So they suggest 3 levels. I'll 
repeat our current release process *in practice* only has two levels: major 
releases and bug fix releases. The latter can also include smaller features 
and enhancements. The former can be a mix of all: bugfixes, new features and 
major changes.

> 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?
> 
While a valuable suggestion a date based system has a few major drawbacks for 
me:
1. it doesn't convey any semantic information at all. So from a purely date 
based system a user can't tell whether the new version comes with incompatible 
changes or not.
2. it tends to be associated with releases at fixed intervals. While our bug 
fix releases are more or less at fixed intervals we currently don't make that 
same commitment for our major releases. In addition we still have a very slow 
major development cycle (3+ years).
3. As we do make a distinction between bugfix and major releases, a hybrid 
form could be to update a date number for major releases and update an 
incremental number for bugfix releases. Given our slow major cycle we'd jump 
from say 18.x to 21.0 on the first next major release. So if users expect the 
first number to be a year, version 18.y would look quite dated and stale in 
the year 2020, something we hoped to avoid instead with a year based scheme.

> > 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)
> 
Because we don't make a distinction between a small compatible new feature and 
a bugfix.

And as said earlier, making a distinction between features and bugfixes would 
require a different release model possibly involving more work than we can 
manage.

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

No. Our distinction is not features vs bugfixes. Our distinction is 
incompatible changes vs (small) features/bugfixes.

> A date based system would solve this perception as noted.

I mentioned my reservations higher up in this mail. We do have a two level 
release model and this can't be encapsulated in a  purely date based system. 
The hybrid model would still have the perception issue.

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

I agree this can be useful and it something we have in mind at some point when 
libgnucash becomes more mature as an independent library. As things stand now 
there is not much point in this yet.

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

.900 and .901 and such are independent of .1 and .2 and so on. They represent 
a different release series which follow their own release cadence. Typically 
the x.900 series will only appear near the end of the development cycle for 
version (x+1).0.

There should be no misunderstanding between .9 and .900, just like it should 
be clear .1 comes before .10.

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

That's an alternative option which I conceptually like. However that would 
require us to change parts of our build system that currently can't' handle 
characters in the version numbers.

Regards,

Geert