Difference between revisions of "Simplified Release Process Proposal"

From D Wiki
Jump to: navigation, search
m (Update to current naming convention)
(replaced by DIP75)
 
(3 intermediate revisions by 3 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 -m v2.xxx.0-bx 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 -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
 
</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 -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
 
</source>
 

Latest revision as of 14:50, 4 October 2015

Redirect to: