You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 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.

 

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).

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

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

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. 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.

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.

History of this document

This is the original diagram that was included (added for archiving purposes)

  • No labels