Define branching model

[cornelius]

We need to define how we use git branches, what are the expectations in terms of stability on which branches, from which branches to do releases, how changes propagate between branches, etc.

One option would be to follow the bitcoin model:

They have release branches for release trains such as 0.16 and 0.17, then there is master, and that's it.

A release branch in bitcoin is mostly a stable snapshot. At some point they branch off of master and start polishing, which is mostly finishing the release notes, generating man pages, etc. The release process is outlined in https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md

Patches for CVEs are backported into the release branches (if applicable).

Here is how their release schedule looks like: bitcoin/bitcoin#14438

Another option would be to follow a devel/master model (see for example one variant in "a successfull git branching model", we might want to use a simplified version, though). One advantage of using master to release from is that it's a stable branch name, so CI or other tooling doesn't have to be reconfigured for each release.

A related aspect is how to handle work which is in progress. While we do want to encourage developers to submit code soon and often, stable branches should not be broken by unfinished code. Feature flags might be one way how to address this, so that code can mature on different schedules in the same branch, that might not work for all features, though.

[mergeable]

There has not been any activity in the past month. Is there anything to follow-up?

[scravy]

I think this is pretty much defined by now, or not? @cornelius

[cornelius]

As we are not doing releases yet, the current branching model is very simple as it's basically only master plus personal forks.

When doing releases this will be more elaborate. We have at least to document what we are doing then. So I would leave the issue open for now until we have some more of the release process in place.

[cornelius]

@thothd and me just had a discussion about versioning of documentation (i.e. what we publish on http://docs.unit-e.io) which is related to the branching model. The idea is to keep the same branch structure as the code and generate documentation for each branch which reflects a version. So we would have something like (version numbers are just made up placeholders):

• master: latest development
• 1.0: first major release
• 1.1: update of first major release
• 2.0: second major release

So we would have these branches in both the code and the documentation repository.

[mergeable]

There has not been any activity in the past month. Is there anything to follow-up?

[mergeable]

There has not been any activity in the past 10 days. Is this still active?