You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by bu...@apache.org on 2014/09/27 05:12:12 UTC
svn commit: r923775 - in /websites/staging/accumulo/trunk/content: ./
git.html
Author: buildbot
Date: Sat Sep 27 03:12:12 2014
New Revision: 923775
Log:
Staging update by buildbot for accumulo
Modified:
websites/staging/accumulo/trunk/content/ (props changed)
websites/staging/accumulo/trunk/content/git.html
Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Sep 27 03:12:12 2014
@@ -1 +1 @@
-1627878
+1627921
Modified: websites/staging/accumulo/trunk/content/git.html
==============================================================================
--- websites/staging/accumulo/trunk/content/git.html (original)
+++ websites/staging/accumulo/trunk/content/git.html Sat Sep 27 03:12:12 2014
@@ -295,8 +295,8 @@ Jira issue ACCUMULO-12345 that affects 1
</li>
<li>
<p>For the given issue you intend to work on, choose the 'lowest' fixVersion
- and create a branch for yourself to work in. This example is against fixVersion 1.5.2.</p>
-<p><code>git checkout -b ACCUMULO-12345-my-work origin/1.5.2-SNAPSHOT</code></p>
+ and create a branch for yourself to work in. This example is against the next release of 1.5</p>
+<p><code>git checkout -b ACCUMULO-12345-my-work origin/1.5</code></p>
</li>
<li>
<p>Make commits as you see fit as you fix the issue, referencing the issue name
@@ -320,12 +320,12 @@ This commit adds a delay to the end of t
<p>Assuming others are developing against the version you also are, as you
work, or before you create your patch, rebase your branch against the remote
to lift your changes to the top of your branch. The branch specified here should be the same one you used in step 4.</p>
-<p><code>git pull --rebase origin 1.5.2-SNAPSHOT</code></p>
+<p><code>git pull --rebase origin 1.5</code></p>
</li>
<li>
<p>At this point, you can create a patch file from the upstream branch to
attach to the ACCUMULO-12345 Jira issue. The branch specified here should be teh same one you used in step 4.</p>
-<p><code>git format-patch --stdout origin/1.5.2-SNAPSHOT > ACCUMULO-12345.patch</code></p>
+<p><code>git format-patch --stdout origin/1.5 > ACCUMULO-12345.patch</code></p>
</li>
</ol>
<p>An alternative to creating a patch is submitting a request to pull your changes
@@ -346,25 +346,11 @@ free of unnecessary merges.</p>
<h2 id="developers">Developers</h2>
<h3 id="primary-development">Primary Development</h3>
<p>Primary development should take place in <code>master</code> which is to contain the most
-recent, un-released version of Apache Accumulo.</p>
-<p>For changes staged for the next minor release of Apache Accumulo, it has been
-suggested that a branch is created for the purpose of containing the bug-fixes,
-API-compatible improvements and backported-features. This provides the
-following:</p>
-<ol>
-<li>Avoids many long-running 'SNAPSHOT' branches to force the developer to best
- consider where his/her changes should be applied.</li>
-<li>Better ties a branch containing commits for a minor release to Jira issues
- fixed in said minor release.</li>
-</ol>
-<p>If said short-lived branch doesn't yet exist, the developer should create said
-branch off of the last minor release in the targeted major version.</p>
-<p>For example, if a developer finds a fix that needs to be made against the 1.4.3
-release of Apache Accumulo, the developer should create a new branch from the
-1.4.3 tag, apply the changes, and push the branch remotely with an appropriate
-name. It has been suggested to name the branch in the same manner in which
-Maven releases are named. In other words, the branch just created would be
-named <code>1.4.4-snapshot</code> or similar.</p>
+recent, un-released version of Apache Accumulo. Branches exist for minor releases
+for each previously released major version. </p>
+<p>Using long-lived branches that track a major release line simplifies management and
+release practices. Developers are encouraged to make branches for their own purposes,
+for large features, release candidates or whatever else is deemed useful.</p>
<h3 id="reviewing-contributor-changes">Reviewing contributor changes</h3>
<p>It is always the responsibility of committers to determine that a patch is
intended and able to be contributed. From the
@@ -383,8 +369,8 @@ list of commits sent to the Accumulo dev
contributors:</p>
<ol>
<li>
-<p>Checkout the branch which the patch is submitted for:</p>
-<p><code>git checkout 1.5.1-SNAPSHOT</code></p>
+<p>Checkout the branch for the major version which the patch is intended:</p>
+<p><code>git checkout 1.5</code></p>
</li>
<li>
<p>Verify the changes introduced by the patch:</p>
@@ -400,11 +386,11 @@ contributors:</p>
</li>
<li>
<p>When finished, push the changes:</p>
-<p><code>git push origin 1.5.1-SNAPSHOT</code></p>
+<p><code>git push origin 1.5</code></p>
</li>
<li>
<p>Merge where appropriate:</p>
-<p><code>git checkout master && git merge 1.5.1-SNAPSHOT</code></p>
+<p><code>git checkout master && git merge 1.5</code></p>
</li>
</ol>
<h4 id="github-pull-requests">Github Pull-Requests</h4>
@@ -536,17 +522,19 @@ next minor release is '1.6.1'. These cha
client code which works against <code>z</code> and should absolutely not change the public
API.</p>
<p>By convention, the branch containing the changes <code>z'</code> should be named
-<code>x.y.z'-SNAPSHOT</code>. The steps to take are as follows:</p>
+<code>x.y</code> (where the changes for <code>z'</code> are commits since <code>x.y.z</code>. The steps to take are as follows:</p>
<ol>
<li>Prepare the release candidate. <a href="/governance/releasing.html">Release
Guide</a>, <a href="/releasing.html">Maven
Instructions</a></li>
-<li>Create a tag of the release candidate from the <code>x.y.z'-SNAPSHOT</code> branch,
- named something like <code>x.y.z'-RC-N</code>.</li>
+<li>Create a branch for the release candidate from the <code>x.y</code> branch,
+ named something like <code>x.y.z'-RCN</code>.</li>
<li>Test and Vote</li>
-<li>Create a tag with the correct final name: <code>x.y.z'</code></li>
-<li>Push a delete of the remote branch <code>x.y.z'-SNAPSHOT</code></li>
+<li>Create a GPG-signed tag with the correct final name: <code>x.y.z'</code></li>
+<li>Push a delete of the remote branch <code>x.y.z'-RCN</code></li>
</ol>
+<p>This process is not firm and should not be viewed as requirements for making a release.
+The release manager is encouraged to make use branches/tags in whichever way is best.</p>
<h3 id="a-major-release">A major release</h3>
<p>A major release is a release in which multiple new features are introduced
and/or the public API are modified. The major release <code>y'</code>, even when the
@@ -556,11 +544,11 @@ the <code>z</code> value back to <code>0
<p>The steps to create a new major release are very similar to a minor release:</p>
<ol>
<li>Prepare the release candidate. <em>reference release instructions</em></li>
-<li>Create a tag of the release candidate from the <code>x.y.0'-SNAPSHOT</code> branch,
- named something like <code>x.y.0-RC-N</code>.</li>
+<li>Create a tag of the release candidate from the <code>x.y</code> branch,
+ named something like <code>x.y.0-RCN</code>.</li>
<li>Test and Vote</li>
-<li>Create a tag with the correct final name: <code>x.y.0</code></li>
-<li>Push a delete of the remote branch <code>x.y.0-SNAPSHOT</code></li>
+<li>Create a GPG-signed tag with the correct final name: <code>x.y.0</code></li>
+<li>Push a delete of the remote branch <code>x.y.0-RCN</code></li>
</ol>
<h1 id="the-infrastructure">The infrastructure</h1>
<p>This section deals with the changes that must be requested through INFRA. As
@@ -578,7 +566,7 @@ how we currently track "Accumulo" projec
<li>
<p>One repository for every project in
<a href="https://svn.apache.org/repos/asf/accumulo/contrib">contrib</a>: Accumulo-BSP,
- Instamo Archetype, Accumulo Pig, and the Wikisearch project. Each of these
+ Instamo Archetype, and the Wikisearch project. Each of these
are considered disjoint from one another, and the main source tree, so they
each deserve their own repository.</p>
</li>
@@ -604,63 +592,29 @@ variables</a>.</p>
<h2 id="releasing-160">Releasing 1.6.0</h2>
<ol>
<li>
-<p>Branch from <code>master</code> to <code>1.6.0-SNAPSHOT</code></p>
-<p><code>git checkout master && git branch 1.6.0-SNAPSHOT</code></p>
+<p>Branch from <code>master</code> to <code>1.6</code></p>
+<p><code>git checkout master && git branch 1.6</code></p>
</li>
<li>
-<p>Tag <code>1.6.0-RC1</code> from the just created <code>1.6.0-SNAPSHOT</code> branch</p>
-<p><code>git tag 1.6.0-RC1 1.6.0-SNAPSHOT</code></p>
+<p>Tag <code>1.6.0-RC1</code> from the just created <code>1.6</code> branch</p>
+<p><code>git tag 1.6.0-RC1 1.6</code></p>
</li>
<li>
<p>Test, vote, etc. and tag from 1.6.0-RC1</p>
-<p><code>git tag 1.6.0 1.6.0-RC1</code></p>
+<p><code>git -s tag 1.6.0 1.6.0-RC1</code></p>
</li>
<li>
<p>Delete the RC tag, if desired.</p>
<p><code>git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1</code></p>
</li>
<li>
-<p>Delete the <code>1.6.0-SNAPSHOT</code> branch</p>
-<p><code>git branch -d 1.6.0-SNAPSHOT && git push --delete origin 1.6.0-SNAPSHOT</code></p>
-</li>
-<li>
<p>Ensure <code>master</code> contains all features and fixes from <code>1.6.0</code></p>
-<p><code>git checkout master && git merge 1.6.0</code></p>
+<p><code>git checkout master && git merge 1.6</code></p>
</li>
<li>
<p>Update the project version in <code>master</code> to 1.7.0-SNAPSHOT</p>
</li>
</ol>
-<h2 id="found-urgent-bug-in-160">Found urgent bug in 1.6.0</h2>
-<ol>
-<li>
-<p>Determine earliest, still-supported release which bug affects.</p>
-<ul>
-<li>Assume 1.4 is said version with 1.4.3 being the last released version</li>
-<li>For 1.5, use 1.5.1 and 1.6, use 1.6.0.</li>
-</ul>
-</li>
-<li>
-<p>Verify bug does affect 1.4.3</p>
-</li>
-<li>
-<p>Make a branch for each SNAPSHOT version, where one does not already exist</p>
-<p><code>git branch 1.4.4-SNAPSHOT 1.4.3 && git branch 1.5.2-SNAPSHOT 1.5.1 && git
-branch 1.6.1-SNAPSHOT 1.6.0</code></p>
-</li>
-<li>
-<p>Fix the bug in <code>1.4.4-SNAPSHOT</code></p>
-<p><code>git commit -av && git push origin 1.4.4-SNAPSHOT</code></p>
-</li>
-<li>
-<p>Merge from <code>1.4.4-SNAPSHOT</code> to <code>1.5.1-SNAPSHOT</code></p>
-<p><code>git checkout 1.5.1-SNAPSHOT && git merge 1.4.4-SNAPSHOT</code></p>
-</li>
-<li>
-<p>Merge from <code>1.5.1-SNAPSHOT</code> to <code>1.6.1-SNAPSHOT</code></p>
-<p><code>git checkout 1.6.1-SNAPSHOT && git merge 1.5.1-SNAPSHOT</code></p>
-</li>
-</ol>
</div>
<div id="footer">