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