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.

= Versioning scheme =
Versions are numbered according to [http://semver.org semantic versioning], 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 =

Target branching model is much similar to the one presented at [http://nvie.com/posts/a-successful-git-branching-model/ nvie.com] so that we will have:
 * A single main repository (as we already have) with only two branches on it:
   * '''master''', which is the currently available one and which will be the main development branch to where patches continue to be sent via the patch manager;
   * '''release''', (where we branch straight ahead to consolidate and roll out 8.X-rc1) which from now on becomes our "release line" where we prepare 8.4 and maintain it if need be until the next release.

So next steps are:
 1. Back up the repo (always be on the safe side);
 1. pick the latest git commit, build and test it manually with systemtests (while bitten gets fixed or replaced by something else like [http://hudson-ci.org/ Hudson];
 1. if it builds and all test pass (as should already be) then merge it to the newly created "release" branch (manually via direct git edit while the patch manager gets updated to support it);
 1. Generate rpm and source tgz archives from the branch making them available for download, marking them as 8.4.0-rc1 (we should also introduce beta testing in the cycle but for now we have some user tests made directly on the dev branch already ongoing);
 1. Announce the availability of the packages to the community for download and testing.

= Open issues =

== Maintenance ==
The two lines model allows only maintenance until next release comes out (which enables hotfixes but not long term maintenance). This could be addressed by multiple branching model and, given enough resources availability, can also be done on a case-by-case basis but its currently not supported by the community.

== 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 ==
The patch manager should be tested with the updated repo meanwhile and patches sent to it as bugfixes for 8.4.0-rc1 merged manually to the release line. Patch manager needs updating to support a branching model.