On development/release processes and version numbers

[cicko]

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