On development/release processes and version numbers

Thu Jan 25 16:28:04 EST 2018

For clarification, Ubuntu supports their LTS for 5 years, (both desktop and server) but they release one every 2 years. Debian adopted a similar approach, but the two are a year out of sync.

As most know, Ubuntu uses a date based version numbering scheme with point releases for bug fixes. Debian also uses a timed-release model, but they use x.y.z notation instead of yy.mm.z

RHEL offers standard support for 5 years, but they have 3 additional support levels topping out at 10 years total, with the option for special add-on support long beyond that. (for the right price I’m sure) I didn’t check their release cadence against Debian/Ubuntu.

Libreoffice also uses a time-based release x.y.z scheme where ’x’ is the next major release (in their case, every 2.5 years), ‘y’ includes new features and is released every 6 months (supported for 9) and ‘z’ is a monthly bug-fix release. They support 2 released x.y versions at a time (for about 9 months each) with a third being always bleeding edge as the next release. They do note that this process is resource intensive despite (or because of) their large team. I would think this has more to do with the tight schedule though rather than the general scheme itself.

If the goal is to look ‘fresh’ for users, then I’d think a time-based numbering scheme is the way to go. (either by dates, or x.y.z) But if semantic versioning is more important, then you’re destined to appear ‘stale’ since development of major improvements is slow to occur due to a small team and limited resources. (not that I think anyone is complaining, everyone working on this project is much appreciated)

Based on the GnuCash release cadence I would think a 2 year LTS policy would be sufficient to maintain with bug-fixes only, while all new features (even minor ones) and major changes go into the ‘fresh’ version. Two versions seems like the least amount of work and is pretty fair.

There are two other topics that might assist with the ‘stale vs. fresh’ impression: reports and modules. Judging by the mailing list topics, it seems reporting is the area users care most about having as a new ‘feature’ than actual application functionality. Certainly, reports can be added or improved for the LTS users since they are able to be installed separately and don’t really constitute new ‘features’ in the main app. As long as the plugin-module model is supported, that route can offer ‘new features’ as well until they are integrated into main. With those two in mind, the LTS policy could even be 5 years since it would be possible to add-on needed improvements while the core dev work is on toolkits, MVC, language rebasing and moving to full database usage. (those report writers and plugin maintainers would have to keep up with the ‘fresh’ version of course, maybe even merging into it for the next major release, but their original code will last as long as the LTS policy)

Just some thoughts,
Adrien

> On Jan 25, 2018, at 1:41 PM, cicko <alen.siljak at gmx.com> wrote:
> 
> Looks like a start of an interesting discussion.
> I'll chip in just a few drops at this time and won't repeat myself in terms
> of personal preferences for the version numbers because there are other
> concerns to take into consideration there, as well.
> 
> The release management need not necessarily be tied to the development and
> code branching strategy. Here is an interesting model that I've tried to
> emulate in practice but never got as far as having the full spectre of
> branches in a repo (mostly because I never had git in professional projects
> and Open Source ones are fairly small for the full model :'( ). It is
> interesting, nonetheless, to read into it and utilize the ease of switching
> and merging branches git provides.
> http://nvie.com/posts/a-successful-git-branching-model/
> In brief, you could still have two main branches: unstable and stable. There
> are numerous other branches in practice. The feature branches merge to
> unstable, while hotfixes merge to stable branch. In this model, master is
> the stable branch, the mirror image of the GnuCash branch stability, but the
> practical difference is just in branch names. The code flow is likely still
> the same. What I find quite practical with git is that there can be lots of
> active branches that span from the main two - unstable and stable - and are
> used for new feature development or bug fixes.
> An opposite, perpendicular approach would be a branch per version number.
> This model is more oriented towards end-users and, in my opinion, makes more
> sense for large providers with a large and profitable user base. This seems
> very demanding on the development team as well as the release management
> process.
> 
> As far as product management goes, with release version numbers, there will
> be lots of factors, I guess. As you mentioned, supporting certain versions
> in order to follow other vendors' policies might be one. But, politics
> aside, what I find practical for the release schedule GnuCash follows at the
> moment, is to have the version numbers still provide the information with
> semantic versioning but not necessarily providing much overhead in terms of
> maintaining the code branches. What I mean is, the numbers increase like on
> a measuring device. The third number (bugfix) releases happen only until the
> next minor version comes out. Then this becomes the latest version and
> bugfixes are release only for this version. I.e.
> - you do some work -> release 1.0.0
> - features are being developed in feature branches
> - bug found. Release goes out, not waiting for the features to be complete.
> -> 1.0.1
> - one feature complete -> 1.1.0
> - another bug fixed -> 1.1.1
> - big feature complete -> 2.0.0
> - another bug fixed -> 2.0.1
> and so on.
> There are several aspects here. Once a minor release is out, the maintenance
> is only done on that latest release, not on any of the previous ones. Users
> are expected to upgrade because there are no breaking changes involved.
> Releasing a major version might be a different story but in the simple case
> everything goes just like with minor version. Whether and for how long the
> previous versions are supported in practice depends on several factors:
> - the amount of development overhead and effort in maintaining the previous
> releases,
> - the amount of time/effort that goes into testing the future releases
> (meaning how stable they are in their x.0.0 version).
> Maintaining several active versions requires decent amount of testing of
> *all* of them and I am not a big fan of that scenario. That grows the
> efforts exponentially while providing a questionable result. You'll have to
> weigh on whether the results are worth the effort.
> 
> The versions also do not need to be scheduled, although that's a nice touch
> when I look from the end-user's perspective. You could simply release
> whenever there are some updates. This gets both the features and bug fixes
> into production faster. Which is not necessarily always a good thing. 
> 
> These are just some observations that may or may not apply to GnuCash. But I
> always enjoy the discussion about these matters. :)
> 
> 
> 
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel