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 =
Versions are numbered according to [http://semver.org semantic versioning] (we may reference the fields X.Y.Z as M.m.p to better indicate Major, minor and patch numbering), starting with 8.4.0. Tentative interface definition is defined by the standards supported in the [wiki:Features features matrix] and the command line tools parameters.

= Initial process =

A single main repository is maintained (as we already have).

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.
  * 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 local branch can be checked out
{{{
git checkout release_M.m
}}}

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.

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
}}}


Releases can only be made if the [http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/build build status] is successful for the latest commit.

= Open issues =

== 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.

== Patch manager with branches ==
Patch manager will be updated to support the branching model.

== 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.