|
|
(One intermediate revision by one other user not shown) |
Line 1: |
Line 1: |
− | 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.
| + | #REDIRECT [[DIP75]] |
− | | |
− | | |
− | <pre>
| |
− | [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
| |
− | </pre>
| |
− | | |
− | | |
− | | |
− | ==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:
| |
− | | |
− | <source lang="bash">
| |
− | git checkout -b 2.xxx master
| |
− | git push upstream 2.xxx
| |
− | </source>
| |
− | | |
− | As bugfixes come in cherry-pick them from master:
| |
− | | |
− | <source lang="bash">
| |
− | # while "2.xxx" is checked out | |
− | git cherry-pick <-m #> <commit-hash>
| |
− | git push upstream 2.xxx
| |
− | </source>
| |
− | | |
− | | |
− | As each beta is made:
| |
− | | |
− | <source lang="bash">
| |
− | git tag -a v2.xxx.0-bx -m v2.xxx.0-bx 2.xxx
| |
− | git push upstream v2.xxx.0-bx
| |
− | </source>
| |
− | | |
− | | |
− | When the final release has been built and is out the door:
| |
− | | |
− | <source lang="bash">
| |
− | git tag -a v2.xxx.0 -m 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
| |
− | </source>
| |
− | | |
− | ===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:
| |
− | | |
− | <source lang="bash">
| |
− | # while the appropriate "2.xxx" is checked out
| |
− | git cherry-pick <-m #> <commit-hash>
| |
− | git push upstream 2.xxx
| |
− | </source>
| |
− | | |
− | | |
− | When the final hotfix release has been built and is out the door:
| |
− | | |
− | <source lang="bash">
| |
− | git tag -a v2.xxx.x -m 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
| |
− | </source>
| |
− | | |
− | | |
− | ----
| |
− | | |
− | [[Category:git]]
| |
− | [[Category:development]]
| |
− | [[Category:know-how]] | |