Building software into a repository is already an improvement over legacy package management, but release and deployment need more management and process than just building software into a versioned repository. Several of Conary's features are useful for managing release and deployment; groups, branches, shadows, redirects, and labels can all help.
Different release goals or deployment needs will result in different policies and processes. This paper uses some concrete examples to demonstrate how Conary features can support a release management process, but the mechanisms are flexible and can support diverse processes. A release can go through one QA step or ten separate QA steps without changing the fundamental processes. Release management and deployment have many of the same needs, so this paper will refer generally to release management except when it is useful to distinguish between the two.
The capabilities needed for release management include:
Collecting troves (including locally modified versions) to create a coherent set for promotion to the next step in the process.
Mandatory or advisory controls on who can or should access a set of troves.
Controlled updates for sets of troves.
In addition, the jargon for talking about Linux distributions is somewhat vague and used in conflicting ways. The following definitions apply to this discussion.
A notionally-connected set of products consisting of an operating system and related components. A distribution might last for years, going through many major release cycles. Examples include rPath Linux, Foresight Linux, Red Hat Linux, Fedora Core, Debian, Mandrake (now Mandriva) Linux, CentOS, cAos, and Gentoo.
One instance of a distribution product, encompassing the entire ``release cycle,'' which might include steps like alpha, beta, release candidate, and general availability. Examples include rPath Linux 1, Red Hat Linux 7.3, Fedora Core 2, etc.
A working space dedicated to a task.
An instance of any step in the distribution release management process. (This is a slightly unusual meaning for ``release;'' ``version'' and ``release'' are often used almost interchangeably, but for the purposes of this discussion, we need to differentiate these two meanings.) This might be alpha 1 release candidate 1, alpha 1 release candidate 2, alpha 1, beta 1, beta 2, release candidate 1, general availability, and each individual maintenance update.
A release of a version of a distribution is defined (in Conary terms) by a unique version of an inclusive group that defines the contents of the distribution. In rPath Linux, that group is called group-os.
The policy and much of the process in this example is synthetic, but the version tree structure it demonstrates (including the names for labels in the example) is essentially the one that we have defined for rPath Linux.
The development branch called /conary.rpath.com@rpl:devel (hence, :devel) is where the latest upstream versions are committed. At some point, a group defining a distribution is shadowed to create release stage, /conary.rpath.com@rpl:devel//rel (hence, //rel) allowing unfettered development to continue on the :devel development branch, while controlled development (a state sometimes called ``slush,'' by analogy from ``freeze'') is now possible on //rel.
Given a very simple, informal release management process—say, one where only one person is doing all the work, following all the process from the time that the initial release stage is created, and in which maintenance does not need to be staged—this single shadow creating a single stage might be sufficient. However, in order to allow any controlled development to happen in parallel with the full release engineering process, and in order to allow maintenance work to be staged, a two-level stage structure is necessary. Generally, another level of stage is added by using the shadow command, and then if and when it is appropriate, that work is promoted back up to the release stage using the clone command.
When controlled development has reached the point where an alpha release is appropriate, another shadow is created on which to freeze that release: /conary.rpath.com@rpl:devel//rel//rel-alpha (hence, //rel-alpha). This allows controlled development to continue on the release stage. Build the shadowed group-os (or whatever you have called your inclusive group), and the version you have just created is a candidate alpha release. Cycle through your test, fix, rebuild process until you have a version of group-os that meets your criteria for release as an alpha. At this point, that specific version of group-os, say group-os=/conary.rpath.com@rpl:devel//rel//rel-alpha/1.0.1-2.3.1-35, is your alpha 1 release.
Note that during the test, fix, rebuild process for alpha 1, development work aimed at alpha 2 can already be progressing on the release stage. Fixes that need to be put on the alpha stage for alpha 1 can either be committed to the release stage and thence shadowed to the alpha stage, or if further development has happened on the release stage that could destabilize the alpha stage, or the immediate fix is a workaround or hack and the right fix has not yet been committed to the release stage, the fix, workaround, or hack can be committed directly to the alpha stage.
Then for the alpha 2 cycle, you re-shadow everything from the release stage to the alpha stage, and start the test, fix, rebuild process over again. When you get to betas, you just create a beta stage: /conary.rpath.com@rpl:devel//rel//rel-beta (hence, //rel-beta) and work with it exactly as you worked with the alpha stage. Finally, when you are ready to prepare release candidates, you can either build them directly onto the release stage, or you can create a //rel//rel-rc stage as a temporary workspace, and then clone the candidates to the //rel stage.
During maintenance, you can do all of your maintenance candidates on the release stage. Alternatively, you can create test stages, and then clone those candidates to the release stage when they finish testing. You can even have multiple stages representing different parts of your test process, and clone from one stage to the next until you are ready to clone to the release stage. Note that those test stages could be protected by different ACLs than your release stage, and can even be hosted on a different repository server. This is particularly useful for security updates or other updates that are not yet public.
All the stages are really labels, as well as shadows. You can shadow any branch you need to onto the release stage, and you will probably want to shadow troves from several branches. Not just /conary.rpath.com@rpl:devel but also branches like /conary.rpath.com@rpl:devel/1.5.28-1-0/cyrus-sasl1/ (hence, :cyrus-sasl1) for different versions where both versions should be installed at once. With that :cyrus-sasl1 branch and cyrus-sasl 2 from the :devel branch both shadowed onto the release stage, the command conary update cyrus-sasl will put both versions on your system.
When the release stage is no longer maintained, you might choose to cook redirects (perhaps only for your inclusive group, perhaps for all the packages) to another, still-maintained release. This is purely a matter of distribution policy.