We already agreed contributions should always go via a PR and require two LGTM’s before we merge. This is the next step: How we should do release management for This page describes the Release Management principles for Apache CloudStack 4.6 and onnewer releases.
Contents:
Table of Contents |
---|
...
...
that require little QA and can thus be released fast and often.
Note | |||||
---|---|---|---|---|---|
| . |||||
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). |
*Coverage may go down if code that was covered is deleted
Note | ||
---|---|---|
| ||
LGTM, "Looks Good To Me" is given once a reviewer of a Pull Requests gives an OK to proceed. Please note:
|
...
...
...
See this wiki article for a guide on how to do it.
...
Git commands:
Code Block | ||
---|---|---|
| ||
# Get the exact same commits from the pull-request (the commit hashes must not change)
git fetch origin pull/${prId}/head:pr/${prId}
# Commit it without fast-forwarding. Type the commit message as detailed below.
git merge --no-ff --log pr/${prId}
# Finally, sign the merge commit.
git commit --amend -s --allow-empty-message -m '' |
An optional helper script with detailed usage and help can be found here.
Code Block | ||
---|---|---|
| ||
# Make sure you're on the branch you want to merge into
git checkout ${branch}
# Merge to the next branch and type the commit message as described below.
git merge --no-ff --log ${branch_to_merge}
|
An optional helper script with detailed usage and help can be found here.
Note |
---|
The tools are located in the CloudStack repository. |
The commit message for a merging a pull request, should look like this:
Merge pullrequestrequest #{pr number} from@@ {user name of pr author}
{pr title} * pr/{pr number}: {list of commit messages} Signed-off-by: {name and email of ACS committer that merges the pr}
It is important the pull request is merged to the branch. This script will help you do that (it will be added to the CloudStack repository).
Usage:
./merge-pr.shgit pr 1234
Detailed usage and help can be found here.
...
It is important the pull request is forward merged to the next branch. This script will help you do that (it will be added to the CloudStack repository).
Usage:
./forwardgit fwd-merge.sh some-branch
Detailed usage and help can be found here.
Note | ||
---|---|---|
| ||
We should all use the same tools to merge pull requests and do forward merges! |
This is the original diagram of the release process that was included on which we started the DISCUSS (added for archiving purposes)
When using these tools and this way of working on Apache CloudStack keep in mind that you work with two origins:
If you merge on a clone of one of them while it is behind on the other (or with its origin) you are merging on a commit that is no longer a HEAD. You will get an error when you push due to conflicts. At this point it is safest to throw away your merge, update (git fetch) you local clones and merge the PR again.
Originally written by Rajani Karuturi in PR 1071:
Code Block |
---|
Initial merge of 4.6 to master
ignored pom.xml version number changes and changes to debian/changelog and engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java
Following commands were executed
1. git checkout 4.6
2. git pull --rebase
3. git checkout master
4. git pull --rebase
5. git fwd-merge 4.6
6. git diff --name-only | grep pom.xml | xargs git checkout --ours
7. git diff --name-only | grep pom.xml | xargs git add
8. git checkout --ours engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java
9. git add engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java
10. git checkout --ours debian/changelog
11. git add debian/changelog
12. # manually edited version number in tools/marvin/marvin/deployAndRun.py and tools/marvin/setup.py
13. git commit
14. git checkout -b "merge-46-to-master"
Send this as a PR |
Monthly release schema
The monthly release schema looks like this:
Day 1: release of 4.x.0
Day 14: release of 4.x.1
Day 14: feature freeze 4.(x+1).0
Day 21: 4.(x+1).0 RC
Day 28: release of 4.x.2
Based on these principles, Rajani Karuturi and Remi Bergsma volunteered to be the Release Managers of Apache CloudStack 4.6.
...
Thanks to Rajani Karuturi, Daan, Miguel Ferreira, Wilder Rodrigues and all others for working on this with me (Remi Bergsma).
...