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

Developing new features

Development should be done in a feature branch, branched off of master
Send a PR to get it into master (2x LGTM applies), represented by the 'feature PR' arrows above
Will only be merged when master is open, will be held otherwise until master is open again

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.

...

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.

Development should be done in a feature branch, branched off of master
Send a PR to get it into master (2x LGTM applies), represented by the 'feature PR' arrows above
Will only be merged when master is open, will be held otherwise until master is open again
No backporting / cherry-picking features to existing branches!

This is the original diagram of the release process that was included on which we started the DISCUSS (added for archiving purposes)

...