We already agreed contributions should always go via a PR and require two LGTM’s before we merge. Let me propose the next step on how I think we should do release management for 4.6 and on.
As a RM I want master to be stable at all times
so that I can create release candidates of high quality
that require little Q&A and can thus be released fast and often.
Requirement
Master needs to be stable at all times.
Stable master means all code can be cleanly compiled, all automated tests are passing (giving enough room for exceptions when automated test are flakey), and test coverage does not go down (otherwise that would render the automated testing less useful every time).
The release process would work like this (x=major, y=minor):
To ensure everything ends up on master, the x.y branch should be merged back to master after bug fixes happen.
When the x.y release is being prepared, master will be “frozen” for new features. Working on new features will continue in feature branches, that can be easily rebased against master since it is stable and only receives bug fixes. The easiest would be to work on a feature branch in your own fork, although committers may choose to maintain a feature branch at the Apache CloudStack git repo instead.
The time master is frozen should be as short as possible. It would be awesome if we could reach a schedule where master is open the first half of a month, and frozen the second half. But let's first try this and see how it works. We'll be able to speed it up as we go.
Once x.y.0 is released, master will be opened for new feature merges. When the new features are in, master will be frozen again, etc. It is expected that the new version can go out soon, as we start off from an already stable master at the exact point the previous release was made.
Since the goal is a stable master, bugfix PRs should go to master first. This way we make sure all upcoming releases have the fix included. Then we should decide if the fix should go to other release branches as wel. It could be that the same patch on master can be applied to the release branch. Or else that the fix needs to reimplemented / back ported due to refactoring (or similar) on master.
When we get a PR that is not against master, we should be extra careful. We should ask people to specify why they want to do this as there could be a valid reason, of course. The danger is forgetting to apply it to master as well, in which case we'll be introducing old bugs again if people upgrade later on. We should prevent that from happening.
Ideally, we maintain master and the latest release branch.
Upgrades should be quick and painless so people can keep close to the latest release. Until we are there we will make sure to support our users as good as we can. We will simply prove upgrades to work.
This is the original diagram that was included (added for archiving purposes)