Difference between revisions of "Simplified Release Process Proposal"
(→Hotfixes: Switch over to using persistent release branches) |
m (Update to current naming convention) |
||
| Line 11: | Line 11: | ||
*--2.xx-------*---*---*----*---------------------*---*---------------> | *--2.xx-------*---*---*----*---------------------*---*---------------> | ||
\ \ \ | \ \ \ | ||
| − | [tag v2. | + | [tag v2.xxx.0-b1] [tag v2.xxx.0] [tag v2.xxx.x] |
| Line 39: | Line 39: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | git checkout -b 2. | + | git checkout -b 2.xxx master |
| − | git push upstream 2. | + | git push upstream 2.xxx |
</source> | </source> | ||
| Line 46: | Line 46: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | # while "2. | + | # while "2.xxx" is checked out |
| − | git cherry-pick <commit-hash> | + | git cherry-pick <-m #> <commit-hash> |
| − | git push upstream 2. | + | git push upstream 2.xxx |
</source> | </source> | ||
| Line 55: | Line 55: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | git tag -m v2. | + | git tag -m v2.xxx.0-bx v2.xxx.0-bx 2.xxx |
| − | git push upstream v2. | + | git push upstream v2.xxx.0-bx |
</source> | </source> | ||
| Line 63: | Line 63: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | git tag -m v2. | + | git tag -m v2.xxx.0 v2.xxx.0 2.xxx |
| − | git push upstream v2. | + | git push upstream v2.xxx.0 |
| − | git push upstream 2. | + | git push upstream 2.xxx |
git checkout master | git checkout master | ||
| − | git merge 2. | + | git merge 2.xxx |
git push upstream master | git push upstream master | ||
</source> | </source> | ||
| Line 78: | Line 78: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | # while the appropriate "2. | + | # while the appropriate "2.xxx" is checked out |
| − | git cherry-pick <commit-hash> | + | git cherry-pick <-m #> <commit-hash> |
| − | git push upstream 2. | + | git push upstream 2.xxx |
</source> | </source> | ||
| Line 87: | Line 87: | ||
<source lang="bash"> | <source lang="bash"> | ||
| − | git tag -m v2. | + | git tag -m v2.xxx.x v2.xxx.x 2.xxx |
| − | git push upstream v2. | + | git push upstream v2.xxx.x |
| − | git push upstream 2. | + | git push upstream 2.xxx |
git checkout master | git checkout master | ||
| − | git merge 2. | + | git merge 2.xxx |
git push upstream master | git push upstream master | ||
</source> | </source> | ||
Revision as of 02:55, 3 April 2014
The following is just a preliminary proposal to simplify the Release Process. The aim is to keep it as simple as possible because there has been a lot of difficulty following the more sophisticated Release Process currently in place.
[Feature PRs] [Bugfix PRs] [ Emergency bug/regression fix PR]
| | | | |
| | | | |
====*==*====*=====*=======*==========*====master=====*=========*============>
\ . . / . /
\ . . / . /
*--2.xx-------*---*---*----*---------------------*---*--------------->
\ \ \
[tag v2.xxx.0-b1] [tag v2.xxx.0] [tag v2.xxx.x]
| = pull request
\ = fork\tag
/ = merge
. = cherry-pick
Contributors
Just make pull requests to master.
Release Manager
Releases
Only the Release Manager needs to do this and they only need to do this during a scheduled feature freeze for an upcoming release. The feature freeze window should be kept short to minimize the work involved.
It's assumed they have a github.com/D-Programming-Language remote setup called "upstream" and master is up-to-date with it.
When a scheduled feature freeze for an upcoming release is to happen just create the versioned release branch:
git checkout -b 2.xxx master
git push upstream 2.xxx
As bugfixes come in cherry-pick them from master:
# while "2.xxx" is checked out
git cherry-pick <-m #> <commit-hash>
git push upstream 2.xxx
As each beta is made:
git tag -m v2.xxx.0-bx v2.xxx.0-bx 2.xxx
git push upstream v2.xxx.0-bx
When the final release has been built and is out the door:
git tag -m v2.xxx.0 v2.xxx.0 2.xxx
git push upstream v2.xxx.0
git push upstream 2.xxx
git checkout master
git merge 2.xxx
git push upstream master
Hotfixes
Hotfixes are emergency releases made because of some very serious bug or regression that cannot wait until the next release is made.
After the regression/bug fix comes in cherry-pick it from master:
# while the appropriate "2.xxx" is checked out
git cherry-pick <-m #> <commit-hash>
git push upstream 2.xxx
When the final hotfix release has been built and is out the door:
git tag -m v2.xxx.x v2.xxx.x 2.xxx
git push upstream v2.xxx.x
git push upstream 2.xxx
git checkout master
git merge 2.xxx
git push upstream master
