Autogenerated HTML docs for v1.6.5.3-298-g39add

1 files changed, 117 insertions, 1 deletions

diff --git a/gitworkflows.html b/gitworkflows.html
index 0159e0147..4a3672e6f 100644
--- a/gitworkflows.html
+++ b/gitworkflows.html
@@ -504,6 +504,122 @@ right after the testing, you can even publish this branch, for example
 to give the testers a chance to work with it, or other developers a

 chance to see if their in-progress work will be compatible.  <tt>git.git</tt>

 has such an official throw-away integration branch called <em>pu</em>.</p></div>

+<h3 id="_branch_management_for_a_release">Branch management for a release</h3><div style="clear:left"></div>

+<div class="para"><p>Assuming you are using the merge approach discussed above, when you

+are releasing your project you will need to do some additional branch

+management work.</p></div>

+<div class="para"><p>A feature release is created from the <em>master</em> branch, since <em>master</em>

+tracks the commits that should go into the next feature release.</p></div>

+<div class="para"><p>The <em>master</em> branch is supposed to be a superset of <em>maint</em>. If this

+condition does not hold, then <em>maint</em> contains some commits that

+are not included on <em>master</em>. The fixes represented by those commits

+will therefore not be included in your feature release.</p></div>

+<div class="para"><p>To verify that <em>master</em> is indeed a superset of <em>maint</em>, use git log:</p></div>

+<div class="exampleblock">

+<div class="title">Recipe: Verify <em>master</em> is a superset of <em>maint</em></div>

+<div class="exampleblock-content">

+<div class="para"><p>git log master..maint</p></div>

+</div></div>

+<div class="para"><p>This command should not list any commits.  Otherwise, check out

+<em>master</em> and merge <em>maint</em> into it.</p></div>

+<div class="para"><p>Now you can proceed with the creation of the feature release. Apply a

+tag to the tip of <em>master</em> indicating the release version:</p></div>

+<div class="exampleblock">

+<div class="title">Recipe: Release tagging</div>

+<div class="exampleblock-content">

+<div class="para"><p><tt>git tag -s -m "GIT X.Y.Z" vX.Y.Z master</tt></p></div>

+</div></div>

+<div class="para"><p>You need to push the new tag to a public git server (see

+"DISTRIBUTED WORKFLOWS" below). This makes the tag available to

+others tracking your project. The push could also trigger a

+post-update hook to perform release-related items such as building

+release tarballs and preformatted documentation pages.</p></div>

+<div class="para"><p>Similarly, for a maintenance release, <em>maint</em> is tracking the commits

+to be released. Therefore, in the steps above simply tag and push

+<em>maint</em> rather than <em>master</em>.</p></div>

+<h3 id="_maintenance_branch_management_after_a_feature_release">Maintenance branch management after a feature release</h3><div style="clear:left"></div>

+<div class="para"><p>After a feature release, you need to manage your maintenance branches.</p></div>

+<div class="para"><p>First, if you wish to continue to release maintenance fixes for the

+feature release made before the recent one, then you must create

+another branch to track commits for that previous release.</p></div>

+<div class="para"><p>To do this, the current maintenance branch is copied to another branch

+named with the previous release version number (e.g. maint-X.Y.(Z-1)

+where X.Y.Z is the current release).</p></div>

+<div class="exampleblock">

+<div class="title">Recipe: Copy maint</div>

+<div class="exampleblock-content">

+<div class="para"><p><tt>git branch maint-X.Y.(Z-1) maint</tt></p></div>

+</div></div>

+<div class="para"><p>The <em>maint</em> branch should now be fast-forwarded to the newly released

+code so that maintenance fixes can be tracked for the current release:</p></div>

+<div class="exampleblock">

+<div class="title">Recipe: Update maint to new release</div>

+<div class="exampleblock-content">

+<div class="ilist"><ul>

+<li>

+<p>

+<tt>git checkout maint</tt>

+</p>

+</li>

+<li>

+<p>

+<tt>git merge --ff-only master</tt>

+</p>

+</li>

+</ul></div>

+</div></div>

+<div class="para"><p>If the merge fails because it is not a fast-forward, then it is

+possible some fixes on <em>maint</em> were missed in the feature release.

+This will not happen if the content of the branches was verified as

+described in the previous section.</p></div>

+<h3 id="_branch_management_for_next_and_pu_after_a_feature_release">Branch management for next and pu after a feature release</h3><div style="clear:left"></div>

+<div class="para"><p>After a feature release, the integration branch <em>next</em> may optionally be

+rewound and rebuilt from the tip of <em>master</em> using the surviving

+topics on <em>next</em>:</p></div>

+<div class="exampleblock">

+<div class="title">Recipe: Rewind and rebuild next</div>

+<div class="exampleblock-content">

+<div class="ilist"><ul>

+<li>

+<p>

+<tt>git checkout next</tt>

+</p>

+</li>

+<li>

+<p>

+<tt>git reset --hard master</tt>

+</p>

+</li>

+<li>

+<p>

+<tt>git merge ai/topic_in_next1</tt>

+</p>

+</li>

+<li>

+<p>

+<tt>git merge ai/topic_in_next2</tt>

+</p>

+</li>

+<li>

+<p>

+&#8230;

+</p>

+</li>

+</ul></div>

+</div></div>

+<div class="para"><p>The advantage of doing this is that the history of <em>next</em> will be

+clean. For example, some topics merged into <em>next</em> may have initially

+looked promising, but were later found to be undesirable or premature.

+In such a case, the topic is reverted out of <em>next</em> but the fact

+remains in the history that it was once merged and reverted. By

+recreating <em>next</em>, you give another incarnation of such topics a clean

+slate to retry, and a feature release is a good point in history to do

+so.</p></div>

+<div class="para"><p>If you do this, then you should make a public announcement indicating

+that <em>next</em> was rewound and rebuilt.</p></div>

+<div class="para"><p>The same rewind and rebuild process may be followed for <em>pu</em>. A public

+announcement is not necessary since <em>pu</em> is a throw-away branch, as

+described above.</p></div>

 </div>

 <h2 id="_distributed_workflows">DISTRIBUTED WORKFLOWS</h2>

 <div class="sectionbody">

@@ -650,7 +766,7 @@ other options.</p></div>
 </div>

 <div id="footer">

 <div id="footer-text">

-Last updated 2009-11-15 09:57:27 UTC

+Last updated 2009-11-21 17:36:59 UTC

 </div>

 </div>

 </body>