Beyond 2.8 - some design thoughts

[Geert Janssens]

Op maandag 25 december 2017 00:34:39 CET schreef John Ralls:
> > On Dec 24, 2017, at 8:34 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:
> > 
> > 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/2.8.99.1 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.
> 
Interesting link though it does indeed target mostly libraries. The Stack 
Exchange link [1] Alen Siljak posted in his reply also suggests semantic 
versioning. However at the same time one of the (highly ranked) answers on 
that page does give reasons why applications may choose not to follow this 
scheme.

I've also read the semantic versioning scheme and I think we have been 
ignoring the distinction between minor and micro for a long time and are 
really using their minor number as our major one. We don't really expose an 
api right now, but we allow things like incompatible config file or data file 
changes only in what we call a major release (like 2.6.0, 2.8.0). We don't 
make a distinction between adding smaller features and bugfixes as long as 
they don't break compatibility. So to my mind our versioning would be semantic 
as well, but with one level of detail less.

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

We could, though I'm not really married to Gnome's guidelines. Also I don't 
really follow the idea of big-bang releases. I'm more in favor of steady, 
incremental development. Having a different number for major changes grows 
wrong user expectations (or disappointments if that number is not changed for 
sufficiently long enough). Simply increasing one number just indicates there's 
progress.

> 
> Should some of the component libraries (especially libgnucash) have separate
> versioning that follows the semantic versioning rules?

Now that is an interesting question. Perhaps we should as soon as libgnucash 
is something worth mentioning on its own and I think even then only if we will 
consider releasing them independently.

And regardless I'd still be fine with a two-number scheme as it reflects our 
development practises more closely than a 3-number one.

If we go for separate versioning at some point I'd make gnucash follow the 
major version of libgnucash.

Lastly, while reading the two links you added I found the even/odd distinction 
is not mentioned at all in semantic versioning but instead is an optional 
gnome thing. And tbh I never really liked it that much :)

Geert

[1] https://softwareengineering.stackexchange.com/questions/255190/how-does-semantic-versioning-apply-to-programs-without-api
[2] https://community.kde.org/Schedules/Frameworks