Page History

...

when voted in, x.y.0 is released and the RC-branch will become x.y branch and tagged x.y.0 on master

To ensure everything ends up on master, the x.y branch should be merged back to master after bug fixes happen.

Preparing new release: master frozen

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.

A release branch is created only at RC-vote time. When te vote passes, the branch is kept to be able to release upcoming point releases from it (x.y.1, x.y.2, etc)
We should only apply critical bug fixes in this release branch, no new features

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)

...