Separate git branches for bug fixes and features

[merkys]

Maybe this is already too late for v1.0.0++, but later on it may be wise to collect bug fixes to one branch, and new features on another. This way we may in parallel develop two releases: next minor and next patch. So if at some point we decide to make a patch release (v1.0.1 as of the time of writing), there would not be a need to check whether develop already includes additions requiring next minor release (v1.1.0).

[ml-evs]

I support this idea, and think we should even consider applying this retroactively. As far as I can see, the only "feature" added since 1.0 is the issue_tracker field.

Would the suggestion be to continue with develop as it is, but backport bug fixes to a new branch stable, or is your suggestion to go the other way and merge bug fixes from stable into develop when required?

Either way, this would have to be done per PR, though there may be some GH action we can use that looks for a PR label, e.g. backport-v1, that could do this automatically.

[merkys]

I support this idea, and think we should even consider applying this retroactively. As far as I can see, the only "feature" added since 1.0 is the issue_tracker field.

Indeed, it was #339. Then there should not be too much of cherry-picking.

Would the suggestion be to continue with develop as it is, but backport bug fixes to a new branch stable, or is your suggestion to go the other way and merge bug fixes from stable into develop when required?

I support the first option. Next minor release will surely contain the bug fixes, so develop should sync from stable.

Either way, this would have to be done per PR, though there may be some GH action we can use that looks for a PR label, e.g. backport-v1, that could do this automatically.

I think the submitter of every PR would indicate whether the PR is a bug fix or a feature by choosing the merge target branch (stable or develop, accordingly). We can think about GH action too.

[ml-evs]

We just discussed this in the meeting. It sounded like there was consensus that we should at least do something to tackle this.

As far as I see it, the options are either:

• create a new branch that is specifically for new features, which has fixes cherry-picked from develop as-and-when
• treat develop as a real development branch, and backport fixes to master, relying on git tags to deal with stable versioning.

I would suggest that the latter makes more sense, but it leaves more work for PR reviewers to dictate whether changes should be backported (see upcoming issue on code owners).

[merkys]

I think that backporting approach would need more effort that the two-branch approach. So I vote for two-branch approach.

[rartino]

As far as I see it, the options are either:

• create a new branch that is specifically for new features, which has fixes cherry-picked from develop as-and-when
• treat develop as a real development branch, and backport fixes to master, relying on git tags to deal with stable versioning.

I would suggest that the latter makes more sense, but it leaves more work for PR reviewers to dictate whether changes should be backported (see upcoming issue on code owners).

I suggest taking inspiration from the "semantic version model" but adjusted to better match our workflow by (i) skipping separate branches for patch versions by just keeping minor version branches and tag releases with a full (major.minor.patch) version number upon release instead, and (ii) let the main ongoing development be in 'develop' (rather than 'master' as shown in the link) and let 'master' always sit at the released version with highest version number.

Hence:

1. Our main development continues in 'develop' (with PRs from forked repo:s and feature branches)
2. We create a new branch now called 'v1.0' and cherry-pick the commits we have in develop that were just bugfixes for 1.0.0.
3. Future changes that make sense both in 'develop' and in 'v1.0' are PR:ed against 'develop' and cherry-picked into 'v1.0'
4. Changes that only make sense against 'v1.0' are PR:ed directly against that branch.
5. We do all future 1.0.x releases from the 'v1.0' branch by tagging them as v1.0.1, v1.0.2, etc.
6. Until we release 1.1.0, at every release of a 1.0.x version, we also merge that state of the 'v1.0' branch into master.
7. The day we release 1.1.0, we create a 'v1.1' branch, release from it and merge it into master.
8. From the 1.1.0 release and onward, any further 1.0.x releases are just released from the 'v1.0' branch by tagging them there, and not merged into master.
9. We continue as described above onward for 'v1.1', 'v1.2', ..., 'v2.0', 'v2.1', ...

The idea going forward is that:

• 'master' is always at the released version with the highest version number.
• 'develop' is the development state that, if released, would be the version with the highest version number.
• branches 'v1.0', 'v1.1', ..., 'v2.0', 'v2.1', ... all keep track of the latest development states for the respective 1.0.x, 1.1.x, ... 2.0.x, 2.1.x, ... versions.
• releases are tags that include a patch number on the 'v1.0', 'v1.1', ... 'v2.0', 'v2.1' branches.

[merkys]

@rartino's suggestion makes sense, but I'd like to avoid cherry-picking as much as possible due to the tediousness of it. Why not replace

3. Future changes that make sense both in 'develop' and in 'v1.0' are PR:ed against 'develop' and cherry-picked into 'v1.0'
4. Changes that only make sense against 'v1.0' are PR:ed directly against that branch.

with

3. Future changes that make sense both in 'develop' and in 'v1.0' are PR:ed against 'v1.0', and 'v1.0' is routinely merged into 'develop'
4. Changes that only make sense against 'v1.0' are cherry-picked out during the merge of 'v1.0' to 'develop'

This reduces amount of cherry-picks by using them for less frequent action.

Edit: reformulated my suggestion.