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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
