Proposed simplification of the branching model

[sphuber]

In the early stages of this repository, the Git flow model was adopted where master would reflect the latest stable release and the develop branch would be used to merge in day-to-day developments. Actual releases are tagged on the master branch and so when a new release is to be made, there would be a merge of develop into master and then after the release commit, master would be merged back into develop.

The Git flow is designed for projects that often maintain multiple versions of a project at the same time and so is overkill for simple projects. AiiDA falls a bit in between. We propose to drop the develop branch and simply keep master as the master branch of development. We have to be a bit careful then, because as soon as we merge breaking changes into master that would become the next major version, at that point we have to essentially create a support/ branch for the current major version and continue development of that version there. This will still require the merging of fixes that go on there onto master so it is not that the new approach will solve all complexity.

Proposed changes:

• Merge develop in master
• Change default branch from develop to master
• Delete develop

Proposed new branch strategy:

• All PRs from will be merged directly into master
• As soon as breaking changes are introduced into master a support/ branch for the current version needs to be created and PRs for that major version are merged into the support/ branch instead.
• Note that in principle support branches are not merged back into master so any important fixes/features made onto a support branch will have to be cherry-picked onto master if they are also relevant for the next major version.
• Releases for the current major version are then tagged on the support/ branch, until the next major version is released off of master.

As you can see, as long as we want to keep more than one major version at a time, there will still be intricacies with making sure features/fixes get on the correct branches. PRs will have to actively decide in what branch to merge. Still, overall it should slightly simplify the release procedure in that it no longer requires merging back and forth between develop and master.

If you have any problems with the proposed strategy, please put them below in a comment.

[giovannipizzi]

Comments:

• with the same logic outlined above, there is still the decision on the name: master (old git default), develop (to clearly indicate it's a development version, not to be used for production), or main (new git default branch name). Since new repos will have the main branch by default, my suggestion is to rename to main now since we're doing the rename anyway, so in the future the AiiDA repo does not sound as using an "old" default name

• I think we can possibly delay the creation of support branches to the moment in which we want to actually add commits, and start off tags. E.g. if we have tagged version 1.6.7 and 2.0.0, and we do a fix in the main branch that will end up in 2.0.1, if we want to backport it we can create the support/1.6.8 branch, continue working on it, and then when we release we just tag it, release it and remove the branch (the git tag should be enough). Does it make sense? (As long as we explain this, it should be clear). Anyway this is a technical detail, also the current approach of keeping a support/1.6.x branch is fine.

• If we start to work on a new major refactor that shouldn't be merged in the main branch yet, we'll use a proper branch name (but this is what we've been doing already, anyway).

All in all, I agree, apart from the discussion on the name: I vote for main + storing the final outcome of this discussion by updating this wiki page - but if develop or master get more votes, I'm OK to go ahead with what the majority prefers.

[sphuber]

It's over complicating things to change the default branch

That is just flipping a switch once in the settings on Github. Hardly overcomplicating. Anyway, if we are renaming to main then we might as well, but if we keep master then the approach I proposed is actually simpler.

[chrisjsewell]

Tu quoque Brute? At least in Slack you were also opposed to that? What changed?

Haha, I think that got a bit lost in translation. Honestly, I do think it's a little virtue signalling, but if you can't beat 'em, join 'em. and it does make it a bit clearer, the change from the current branches. I'm not really that bothered though, it's the conceptual change that is more important

[chrisjsewell]

That is just flipping a switch once in the settings on Github.

But then also everyone having to rebase all their PR branches onto master etc

[sphuber]

The commits on both branches would be identical though, so the rebase is automatic and as if there was no difference

[chrisjsewell]

Yeh again, I'm really not that bothered either way 👍

[sphuber]

Ok, seems that the majority votes in favor of main. Unless there are people with strong arguments against it that haven't had the time to respond yet, this is what we will adopt when releasing v2.0 in a few weeks.