accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From els...@apache.org
Subject svn commit: r1627921 - /accumulo/site/trunk/content/git.mdtext
Date Sat, 27 Sep 2014 03:12:01 GMT
Author: elserj
Date: Sat Sep 27 03:12:01 2014
New Revision: 1627921

URL: http://svn.apache.org/r1627921
Log:
Update Git workflow with new branch names

Modified:
    accumulo/site/trunk/content/git.mdtext

Modified: accumulo/site/trunk/content/git.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/trunk/content/git.mdtext?rev=1627921&r1=1627920&r2=1627921&view=diff
==============================================================================
--- accumulo/site/trunk/content/git.mdtext (original)
+++ accumulo/site/trunk/content/git.mdtext Sat Sep 27 03:12:01 2014
@@ -126,9 +126,9 @@ Jira issue ACCUMULO-12345 that affects 1
     `git fetch && git fetch --tags`
 
 4. 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.
+   and create a branch for yourself to work in. This example is against the next release
of 1.5
 
-    `git checkout -b ACCUMULO-12345-my-work origin/1.5.2-SNAPSHOT`
+    `git checkout -b ACCUMULO-12345-my-work origin/1.5`
 
 5. Make commits as you see fit as you fix the issue, referencing the issue name
    in the commit message:
@@ -157,12 +157,12 @@ Jira issue ACCUMULO-12345 that affects 1
    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.
 
-    `git pull --rebase origin 1.5.2-SNAPSHOT`
+    `git pull --rebase origin 1.5`
 
 7. 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.
 
-    `git format-patch --stdout origin/1.5.2-SNAPSHOT > ACCUMULO-12345.patch`
+    `git format-patch --stdout origin/1.5 > ACCUMULO-12345.patch`
 
 An alternative to creating a patch is submitting a request to pull your changes
 from some repository, e.g. Github. Please include the repository and branch
@@ -185,27 +185,12 @@ free of unnecessary merges.
 ### Primary Development
 
 Primary development should take place in `master` which is to contain the most
-recent, un-released version of Apache Accumulo.
+recent, un-released version of Apache Accumulo. Branches exist for minor releases
+for each previously released major version. 
 
-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:
-
-1. Avoids many long-running 'SNAPSHOT' branches to force the developer to best
-   consider where his/her changes should be applied.
-2. Better ties a branch containing commits for a minor release to Jira issues
-   fixed in said minor release.
-
-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.
-
-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 `1.4.4-snapshot` or similar.
+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.
 
 ### Reviewing contributor changes
 
@@ -228,9 +213,9 @@ list of commits sent to the Accumulo dev
 Developers should use the following steps to apply patches from
 contributors:
 
-1. Checkout the branch which the patch is submitted for:
+1. Checkout the branch for the major version which the patch is intended:
 
-    `git checkout 1.5.1-SNAPSHOT`
+    `git checkout 1.5`
 
 2. Verify the changes introduced by the patch:
 
@@ -246,11 +231,11 @@ contributors:
 
 5. When finished, push the changes:
 
-    `git push origin 1.5.1-SNAPSHOT`
+    `git push origin 1.5`
 
 6. Merge where appropriate:
 
-    `git checkout master && git merge 1.5.1-SNAPSHOT`
+    `git checkout master && git merge 1.5`
 
 #### Github Pull-Requests
 
@@ -376,16 +361,19 @@ client code which works against `z` and 
 API.
 
 By convention, the branch containing the changes `z'` should be named
-`x.y.z'-SNAPSHOT`. The steps to take are as follows:
+`x.y` (where the changes for `z'` are commits since `x.y.z`. The steps to take are as follows:
 
 1. Prepare the release candidate. [Release
    Guide](/governance/releasing.html), [Maven
    Instructions](/releasing.html)
-2. Create a tag of the release candidate from the `x.y.z'-SNAPSHOT` branch,
-   named something like `x.y.z'-RC-N`.
+2. Create a branch for the release candidate from the `x.y` branch,
+   named something like `x.y.z'-RCN`.
 3. Test and Vote
-4. Create a tag with the correct final name: `x.y.z'`
-5. Push a delete of the remote branch `x.y.z'-SNAPSHOT`
+4. Create a GPG-signed tag with the correct final name: `x.y.z'`
+5. Push a delete of the remote branch `x.y.z'-RCN`
+
+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.
 
 ### A major release
 
@@ -398,11 +386,11 @@ the `z` value back to `0`.
 The steps to create a new major release are very similar to a minor release:
 
 1. Prepare the release candidate. _reference release instructions_
-2. Create a tag of the release candidate from the `x.y.0'-SNAPSHOT` branch,
-   named something like `x.y.0-RC-N`.
+2. Create a tag of the release candidate from the `x.y` branch,
+   named something like `x.y.0-RCN`.
 3. Test and Vote
-4. Create a tag with the correct final name: `x.y.0`
-5. Push a delete of the remote branch `x.y.0-SNAPSHOT`
+4. Create a GPG-signed tag with the correct final name: `x.y.0`
+5. Push a delete of the remote branch `x.y.0-RCN`
 
 # The infrastructure
 
@@ -421,7 +409,7 @@ how we currently track "Accumulo" projec
 
 2. One repository for every project in
    [contrib](https://svn.apache.org/repos/asf/accumulo/contrib): 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.
 
@@ -452,57 +440,28 @@ For the sake of clarity, some examples o
 
 ## Releasing 1.6.0
 
-1. Branch from `master` to `1.6.0-SNAPSHOT`
+1. Branch from `master` to `1.6`
 
-    `git checkout master && git branch 1.6.0-SNAPSHOT`
+    `git checkout master && git branch 1.6`
 
-2. Tag `1.6.0-RC1` from the just created `1.6.0-SNAPSHOT` branch
+2. Tag `1.6.0-RC1` from the just created `1.6` branch
 
-    `git tag 1.6.0-RC1 1.6.0-SNAPSHOT`
+    `git tag 1.6.0-RC1 1.6`
 
 3. Test, vote, etc. and tag from 1.6.0-RC1
 
-    `git tag 1.6.0 1.6.0-RC1`
+    `git -s tag 1.6.0 1.6.0-RC1`
 
 4. Delete the RC tag, if desired.
 
     `git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1`
 
-5. Delete the `1.6.0-SNAPSHOT` branch
-
-    `git branch -d 1.6.0-SNAPSHOT && git push --delete origin 1.6.0-SNAPSHOT`
-
-6. Ensure `master` contains all features and fixes from `1.6.0`
-
-    `git checkout master && git merge 1.6.0`
-
-7. Update the project version in `master` to 1.7.0-SNAPSHOT
-
-## Found urgent bug in 1.6.0
-
-1. Determine earliest, still-supported release which bug affects.
-
-    * Assume 1.4 is said version with 1.4.3 being the last released version
-    * For 1.5, use 1.5.1 and 1.6, use 1.6.0.
-
-2. Verify bug does affect 1.4.3
-
-3. Make a branch for each SNAPSHOT version, where one does not already exist
-
-    `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`
-
-4. Fix the bug in `1.4.4-SNAPSHOT`
-
-    `git commit -av && git push origin 1.4.4-SNAPSHOT`
-
-5. Merge from `1.4.4-SNAPSHOT` to `1.5.1-SNAPSHOT`
+5. Ensure `master` contains all features and fixes from `1.6.0`
 
-    `git checkout 1.5.1-SNAPSHOT && git merge 1.4.4-SNAPSHOT`
+    `git checkout master && git merge 1.6`
 
-6. Merge from `1.5.1-SNAPSHOT` to `1.6.1-SNAPSHOT`
+6. Update the project version in `master` to 1.7.0-SNAPSHOT
 
-    `git checkout 1.6.1-SNAPSHOT && git merge 1.5.1-SNAPSHOT`
 
  [1]: https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow
 



Mime
View raw message