|
|
| (2 intermediate revisions by 2 users 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>
| |
