On development/release processes and version numbers

[Geert Janssens]

To start, this will be a long read to introspect on our development and 
release processes, where they are now and where the may go in the future. If 
you want to help shape this future, please read on and share your thoughts.


I have started a thread earlier with a proposal to update our versioning 
scheme for the upcoming major release.

So far the short summary is that most agree we can switch to 3.0 rather than 
2.8. The debate is still open on two related aspects:
- should we continue with a 3-level number or switch to a two-level one
- how should we indicate unstable versions: 
  * via a distinction between even/odd number
  * via .9xx
  * via another extension such as alpha/beta (a/b)...

Before bringing this to a final decision I want to make a detour to our 
development and release process ("our processes" in short from now on) as the 
discussion so far has lead in that direction regularly. In the end I believe 
whatever version number scheme we decide upon should reflect how we develop 
and release gnucash.

Current situation:
- we develop on two primary branches: maint and master.
- on the maint branch we accept bugfixes and small compatible features
- all other development goes on master. This includes major refactorings, 
incompatible changes (though we usually do our best to provide compatibility 
code in maint), big new features, important dependency updates,...
- we do regular "stable" releases from the maint branch (once every 3 months, 
or once every month early in the stable cycle)
- we never release from master. Near the end of a major cycle (which is not 
strictly defined) we branch off a separate branch to stabilize whatever is on 
master at that point and do beta releases from that separate branch (monthly).


However due to our current version number scheme users and distro maintainers 
seem to believe we have 3 levels of development, usually seen as
- bugfixes
- new features (I'll refer to those as enhancements from now on to avoid 
confusion with our current use of the term 'feature branch')
- incompatible changes

I personally care more about stability than about a distinction between pure 
bugfixes and enhancements. Others appear to believe the former can only exist 
thanks to the latter though. Some distros have strict bugfix-only policies in 
stable releases.

This conflict between actual development process and user perception was one 
of the reasons I started this whole version proposal. Originally it didn't 
even occur to me we could question our processes. I immediately proposed to 
switch to a 2 level version number. And even when others pointed out the other 
possibility my knee-jerk reaction was still adjusting our processes to 
accommodate 3 levels would increase the maintenance burden too much.

But does it ? Let's do at least the thought experiment.
What assumptions do we have about our processes that may no longer be relevant 
now ? Below I'll put up an alternative process for others to think about. It's 
not intended to be the perfect solution, but something to start the 
discussion.

1. A 3-level development model would require 3 rather than 2 primary branches 
in git: master (as now), enhancements (for compatible enhancements) and 
bugfixes (for guess what). In the svn days, everybody would cringe even at the 
thought of having yet another branch to maintain. However in git this has 
become relatively painless. There are still merge conflicts but git really 
goes a long way in making multiple branch development pretty manageable. So 
having a 3-level branch strategy would be realistic. bugfix would be the 
oldest branch. Everything committed to bugfix would eventually be merged 
upwards into enhancements. And all enhancements and bugfixes would eventually 
get merged upwards in master. So far so good.

2. But what with releases ? It starts simple: one does a bugfix release at 
fixed intervals from the bugfix branch, and enhancement releases from the 
enhancement branch. Both can have their own cadence. However it quickly gets 
more complicated when a bug needs to be fixed in a new enhancement. Now one 
needs a bugfix branch on the enhancement branch and this would happen again 
with the next feature release. So rather than one bugfix branch we'd need a 
bugfix branch starting at each enhancement branch release. Branch-wise git can 
still manage this perfectly fine.

3. So back to release aspect itself. Having more branches means more releases 
as well. As things stand each release takes a substantial amount of time from 
our release manager. I don't know the exact amount, but I know there's a long 
list of manual steps that have to be repeated for each release. If releases 
are not too frequent, this is acceptable. However if the number of releases 
increases, the time spent on doing them will become more significant and that 
would be time our valued release manager can't spend on actually improving 
gnucash. So that's an important question: can we automate our release process 
in order to reduce the time a human needs to spend on it ? I imagine the 
ultimate ideal to be that simply tagging a commit would trigger a full release 
cycle, from building tarballs and assembling installers to uploading them and 
sending out release notifications. A fully automated release may not be 
possible, however with some critical review we may reduce the time spent 
considerably anyway. A minimum amount of time spent is a precondition to doing 
more releases (if that's what we want).

4. Time is closely related to timing. Assuming release time can be reduced to 
being marginal, how frequently would we release bugfixes, enhancements and 
major versions ? We currently follow a 3 month model for bug fixes. Would that 
become a 3-month cycle for enhancement releases and monthly bugfixes, or 
bugfixes only if/when the need arises (perhaps we don't have bugfixes for a 
given cycle, so we can just skip one). Should we rather go for enhancement 
every 6 months (several other big projects seem to like that) ?

5. And lastly EOL management. Assuming we'd really switch to a 3 level 
development model and assuming we'd be able to make the release effort itself 
marginal, how long should each feature release get bugfixes ? As a reference 
I'd look at LTS kind of distributions. On Windows and OS X I think the support 
issue is less tied to external factors (other than a Windows or OS X version 
itself being dropped from support). Ubuntu's LTS is supported for 2 years. 
RHEL releases are supported for 5 years. It would make some sense if we would 
support a bugfix release as long as we want to support its presence in certain 
of these LTS distros. If we want to support RHEL, ideally we'd be shipping 
bugfixes for as long as the version of RHEL is supported. Again I think 
keeping branches alive is relatively effortless (though not completely without 
cost either of course), and the rule to apply bugfixes to the oldest supported 
release would still apply. Release time would be the most restricting factor.

That's a first exploration of a different development and release process. 
Perhaps this is something to consider, or perhaps it's totally not what we 
want. Perhaps it triggers other ideas or possibilities. I'm eager to hear it 
all to eventually synthesize this into a solid and modernized set of processes 
for the future of this project.

Geert