You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 9
Next »
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.
Goal written in “Scrum”-style story
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.
Overview of release process
The release process would work like this (x=major, y=minor):
- start to branch RC off from master for the new upcoming version
- when not voted in, abandon RC branch, make fixes on master and start release process from the beginning
- when voted in, x.y.0 is released and the RC-branch will become x.y branch and tagged x.y.0 on master
![](/confluence/download/attachments/59689415/acs_release_preocess_v1.1.png?version=1&modificationDate=1435861189000&api=v2)
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.
After x.y.0 release, master is open again
- 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.
Release branch
- 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
Bug fixes
- 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 (plan A). Or else that same fix needs to be reimplemented at / ported to the release branch (plan B).
- 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.
![](/confluence/download/attachments/59689415/acs_bigfix_plan_a_v1.0.png?version=1&modificationDate=1435914098000&api=v2)
![](/confluence/download/attachments/59689415/acs_bigfix_plan_b_v1.0.png?version=1&modificationDate=1435914096000&api=v2)
Which releases to maintain?
- 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.
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
- No backporting / cherry-picking features to existing branches!
![](/confluence/download/attachments/59689415/acs_add_new_feature_v1.0.png?version=1&modificationDate=1435907913000&api=v2)
History of this document
This is the original diagram of the release process that was included on which we started the DISCUSS (added for archiving purposes)
![](/confluence/download/attachments/59689415/Screen%20Shot%202015-06-25%20at%2022.57.28.png?version=1&modificationDate=1435836414000&api=v2)