Changes between Version 11 and Version 12 of RasdamanReleaseProcess

Timestamp:

Apr 22, 2013, 2:27:16 PM (11 years ago)

Author:

Piero Campalani

Comment:

typos fix and added single branch cloning

RasdamanReleaseProcess

@@ -4 +4 @@
 Since we are using git for version control there are a few caveats that have to be considered in defining the release process:
  * git is distributed and [http://www.ericsink.com/entries/dvcs_dag_1.html does not keep a linear history] like centralised VCS; 
- * pretty much [http://ricroberts.com/articles/getting-to-grips-with-git-part-2-branches-and-tags everithing is considered a branch];
+ * pretty much [http://ricroberts.com/articles/getting-to-grips-with-git-part-2-branches-and-tags everything is considered a branch];
  * there is a [http://nvie.com/posts/a-successful-git-branching-model/ successful git branching model] out there that we can draw upon.
 
@@ -16 +16 @@
 The repository contains two types of ''branches'' on it:
  * '''master''' (single instance) -- the currently available branch, which will be the main development branch;
- * '''release''' (mulitple instances) -- When starting release process (consolidation of beta, rc, and other testing releases), a ''release'' branch is created with name '''release_M.m'''. These branches will allow maintenance of past releases, while development continues in the master branch.
+ * '''release''' (multiple instances) -- When starting release process (consolidation of beta, rc, and other testing releases), a ''release'' branch is created with name '''release_M.m'''. These branches will allow maintenance of past releases, while development continues in the master branch.
   * Where M=Major version; m=minor version; All patch versions will belong to the same "minor" branch
    * Note: consider broader detail such as per-major version release line (fewer branches) or cleaning up branches for un-maintained versions
 
-As an example consider release 8.4.0 and following bugfixes and regression pathces:
+As an example consider release 8.4.0 and following bugfixes and regression patches:
 {{{
    release_8.4 (branch)
@@ -33 +33 @@
 A local branch can be checked out and with recent versions of git also a remote one with the same name:
 {{{
+#!sh
 git checkout release_M.m
 
 #should give you output similar to:
 Branch release_M.m set up to track remote branch release_M.m from origin.
-Switched to a new branch 'release_M.m'
-
+Switched to a new branch 'release_M.m'`
 }}}
 
@@ -47 +47 @@
 Every release, both testing (cleaned up afterwards) and final, is marked by a ''tag'' according to the pattern '''vM.m.p''' (we are keeping the "v" prefix for historical reasons) in the repo, which can be checked out with
 {{{
+#!sh
 git checkout vM.m.p
+}}}
+
+Single branches may also be clones, in case the whole repo is not needed:
+{{{
+#!sh
+# clone only the `release_8.4' branch, locally
+git clone -b release_8.4 git://kahlua.eecs.jacobs-university.de/rasdaman.git
+
+# [...] Checking out a newly created branch, e.g. `featureX':
+git branch -rv 
+    origin/master               96e9534 Fixed array constant for rgb (Ticket 157)
+    origin/release_8.4          5eacb06 Fix netcdf import when only one variable is imported
+    origin/featureX             1234567 Start implementation of feature X.
+git checkout -b featureX origin/featureX
 }}}
 
@@ -57 +72 @@
 == 1. Create branch and tag according to the aforementioned naming scheme - ''Requires write access to the repo'' ==
 {{{
+#!sh
 VERSION="v$MAJOR.$MINOR.0"
 RELEASE="release_$MAJOR.$MINOR"
@@ -73 +89 @@
 
 {{{
-   * git archive  --output=rasdaman-v8.4.0.tgz v8.4.0   # from local clone
+#!sh
+# from local clone
+git archive  --output=rasdaman-v8.4.0.tgz v8.4.0
 }}}
 {{{
-   * git archive --remote=git://kahlua.eecs.jacobs-university.de/rasdaman.git --output=rasdaman-v8.4.0.tgz v8.4.0 # diretly from repo ''currently not working''
+#!sh
+# diretly from repo ''currently not working''
+git archive --remote=git://kahlua.eecs.jacobs-university.de/rasdaman.git --output=rasdaman-v8.4.0.tgz v8.4.0
 }}}
 
@@ -92 +112 @@
 
 == Testing time ==
-We should estabilish some time frame to advance in the release process: now we wait one week before advancing -rc if bugfixes come in.
+We should establish some time frame to advance in the release process: now we wait one week before advancing -rc if bugfixes come in.
 
 == Patch manager with branches ==