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.