Difference between revisions of "Simplified Release Process Proposal"

From D Wiki
Jump to: navigation, search
(Mistake)
(replaced by DIP75)
 
(14 intermediate revisions by 5 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]
 
    \    \    \      \                        \
 
      \    \    \      \                        \
 
====*==*====*=====*======*=========*====master=====*===============*============>
 
    \            .      .      /                .            /
 
      \            .      .    /                  .          /
 
      *--release----*------*---* [tag v2.xxx]       .        /
 
                                        \              .      /
 
                                        \              .    /
 
                                          *--hotfix------*---* [tag v2.xxx.x]
 
 
 
\ = merge
 
/ = merge then delete branch
 
. = 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 "release" branch:
 
 
 
<source lang="bash">
 
git checkout -b release master
 
git push upstream release
 
</source>
 
 
 
As bugfixes come in cherry-pick them from master:
 
 
 
<source lang="bash">
 
# while "release" is checked out
 
git cherry-pick <commit-hash>
 
git push upstream release
 
</source>
 
 
 
 
 
When a beta is made:
 
 
 
<source lang="bash">
 
# while "release" is checked out
 
git tag v2.xxx-betax
 
git push upstream v2.xxx-betax
 
</source>
 
 
 
 
 
When the final release has been built and is out the door:
 
 
 
<source lang="bash">
 
# while "release" is checked out
 
git tag v2.xxx
 
git push upstream v2.xxx
 
git checkout master
 
git merge release
 
git push upstream master
 
git branch -d release      # delete branch
 
git push upstream :release # delete upstream branch
 
</source>
 
 
 
 
 
===Hotfixes===
 
 
 
Hotfixes are emergency releases made because of some very serious bug or regression that cannot wait until the next release is made.  They work nearly identically to the above instructions for a release but they are forked from the tag of the most recently released version. The branches for them are extremely short lived because they address only one (maybe two) specific issues that have come up.
 
 
 
When it's decided a hotfix is necessary:
 
 
 
<source lang="bash">
 
git checkout -b hotfix v2.xxx
 
git push upstream hotfix
 
</source>
 
 
 
 
 
After the regression/bug fix comes in cherry-pick it from master:
 
 
 
<source lang="bash">
 
# while "hotfix" is checked out
 
git cherry-pick <commit-hash>
 
git push upstream hotfix
 
</source>
 
 
 
 
 
When the final hotfix release has been built and is out the door:
 
 
 
<source lang="bash">
 
# while "hotfix" is checked out
 
git tag v2.xxx.x
 
git push upstream v2.xxx.x
 
git checkout master
 
git merge hotfix
 
git push upstream master
 
git branch -d hotfix      # delete branch
 
git push upstream :hotfix # delete upstream branch
 
</source>
 

Latest revision as of 14:50, 4 October 2015

Redirect to: