Re: On development/release processes and version numbers

[John Ralls]

> On Jan 25, 2018, at 5:42 PM, Glen Ditchfield  wrote:
> 
> Regarding EOL management, I think you will soon have three supported
> "product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
> ...), and a 2.4.x series.   (The level of support might be something
> low like "security fixes only".)  3.1 will likely come out before 2.6.x
> reaches end-of-life.
> 
> If that is correct, you'll have to be able develop bug fixes that don't
> apply to all of the supported series.  I don't think that will be easy
> if you have just one bugfix branch.
> 
> I looked around and couldn't find any helpful Git advice for projects
> that have more than one supported version.  Every detailed work flow
> seemed to assume that there just one blob of current production code,
> and one development branch.  
> 
> Perhaps this would work:
> * Normal development (refactorings, enhancements, etc) goes on master.
> * Every supported series has a branch: for now, create releases-2.6.x
>   and releases-2.4.x.  Bug fixes accumulate on these branches.
> * Use feature branches for development: every enhancement and every
>   bug fix gets its own branch.  Enhancements branch off from master. 
>   Bug fixes for old versions branch off from a releases-* branch.
> * When the time comes to prepare for the GnuCash 3 release, create
>   branch releases-3.0.x from master.  Make any necessary adjustments
>   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
>   work done on master after the branch will be part of v3.1.0.

Nope. We do a final release of the previous stable branch concurrent with the 
first release of the new stable branch, so 2.4 stopped with 2.4.14, released 
the same day as 2.6.0. 2.6 support will end with 2.6.20 that will be released 
with 3.0, and 3.x will be the only supported branch until we start a new 
unstable release cycle in 4 years or so (unless we decide to change the “major” 
release tempo).

There’s a reason that you couldn’t find much about it: It’s rare because it’s 
hard. Even projects that have lots of developers like the Linux Kernel don’t do 
it.

Resource constraints aside, the problem with having more than two branches or 
with letting parallel branches live too long is code divergence and up-merges. 
Merging maint into unstable is already a major pain-point and I’ll be really 
happy to get 3.0 out so that we don’t have to merge from what will then be the 
2.6 branch any more.

If the pace of master development picks up we may have to accelerate the 
“major” release tempo to avoid up-merge problems from converting the main 
engine classes to C++. We’ll see.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Matt Graham]

As a Noob following this with interest:
1. If a platform makes a decision that breaks a previous stable version, it 
could be a case if create a quick fix branch off that version tag, and release 
an extra ".1". So 2.6.1 would become 2.6.1.1. Note that I am assuming that this 
is rare and that most people are keeping up to date with stable releases (so 
most bugs are off that).

2. Ultimately, it sounds like step 1 (regardless of which version control 
labelling is used) is to try to automate as much of the "release process" as 
possible. This frees up time from an experienced coder.
Should we have a separate part of the source code for release scripts (that the 
release manager can just run)? Is this something that people like me can help 
with? (Not that I know enough yet to be much help...)

Thanks and regards,
Matt


 Original message 
From: Glen Ditchfield <gjditchfi...@acm.org>
Date: 26/1/18 12:43 (GMT+10:00)
To: gnucash-devel@gnucash.org
Subject: Re: On development/release processes and version numbers

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master.
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C398a5e971c26478e833508d5645e22fc%7C84df9e7fe9f640afb435%7C1%7C0%7C636525277829194997=jxw9jYSj39B%2B%2ByIsE7ElE8fwm5d6pNFie3JU%2FMpEph4%3D=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Glen Ditchfield]

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.  

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master. 
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Adrien Monteleone]

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

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