Changes between Version 4 and Version 5 of RasdamanReleaseProcess

Timestamp:

Mar 18, 2013, 9:27:56 PM (12 years ago)

Author:

abeccati

Comment:

Corrections to current naming scheme

RasdamanReleaseProcess

@@ -1 +1 @@
 This page is an ongoing effort to document current release process, gather important discussions points from the dev mailing list and progress toward a fully fledged release procedure with as much automation as possible.
+
+= Infrastructure notes =
+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 does not keep a linear history like centralised CVS 
 
 = Versioning scheme =
@@ -10 +14 @@
 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_vM.m'''. These branches will allow maintenance of past releases, while development continues in the master 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.
   * 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
 
-A branch can be checked out
+A local branch can be checked out
 {{{
-git checkout release_vM.m
+git checkout release_M.m
 }}}
 
-NOTE: Is there a way to "export" a tag directly from a remote git repo? This will save users from getting all the clone to just test a beta or rc.
+Note that branches on the main repository are remote branches and need a specific [http://stackoverflow.com/questions/67699/how-do-i-clone-all-remote-branches-with-git checkout procedure] to be worked with.
 
-Every release, both testing (cleaned up afterwards) and final, is marked by a ''tag'' '''vM.m.p''' in the repo, which can be checked out on the relevant branch by
+NOTE: Is there a way to "export" a tag directly from a remote git repo? This will save users from getting all the clone to just test a beta or rc. We provide source tarballs for that meanwhile.
+
+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
 {{{
 git checkout vM.m.p
@@ -39 +45 @@
 == Tags ==
 Do tags belong to a branch or are they still visible repository wide on git?
+ * Looks like tags are still repository wide, need to be tested with tags on remote branches.