As we mature as an organisation we need to refine the release process to ensure that we can maintain a high velocity while also keeping code quality and stability high. This applies to both the OSS go-micro as much as any work on m3o or any other product.
The overarching approach should be to ensure that all changes undergo some form of extended testing period. Remember, the blast radius of errors in our code goes far beyond our own organisation so care must be taken.
We attempted using a git-flow model of branching with a
master branch for both
go-micro. However, Github does not support this model very well due to the way it tracks commits and diffs. See https://github.community/t/github-pull-requests-showing-invalid-diff-for-already-merged-branch/559. TLDR if you try to maintain two parallel branches you’ll quickly end up in a position where diffs show, incorrectly, that there are missing commits. e.g. after a couple of releases if you do a compare between
master github will show you that there are differences between the two where in fact there isn’t. Another downside of this approach was when accepting PRs from the community, outside contributors don’t know to branch and PR against
develop, rather, they do it against
master and things very quickly get messy.
The above points to the fact that it is easiest to maintain a single branch,
master, and create feature branches off that i.e. using the Github Flow. This is what projects like kubernetes and terraform do so we’re in good company.
micro project can be consumed as both tagged releases and directly from
We will have 1 long lived branch;
master- reflects the latest and greatest development. All code is reviewed before being merged in to this branch
All feature branches will be branched from and merged back to
master via the usual PR process.
New release candidates will be cut from the
master branch roughly every 2 weeks. New minor releases are cut from the
master branch as
release-X.X. From this point, only bug fixes should be added to the release branch.
If all clear after 7 days we will promote the release candidate to full version and cut a new release which means
release-X.Xbranch with the new release version
release-X.Xbranch is not deleted. It will be retained for any future patch fixes that may be required.
Bug fixes should be made on the
release-X.X branch, tagged, and then merged back to
Testing will include
We follow the semantic versioning approach to release names.
Just before we cut a new major release (v3, v4, etc) we should also create a branch of master to be maintained as the ongoing branch for the current release. This will allow us to provide bugfix support more easily for the release while the master branch moves on to the next major release. For example, before we start work on
v3 we should create a new branch from