Difference between revisions of "Release branches"

Revision as of 17:56, 21 November 2007

MIT Kerberos creates release branches or forks of the code in its Subversion repository in order to provide stability and tighter control as releases approach. Normally development is done on the trunk; all committers can make changes to introduce new functionality and bug fixes there.

While we try to keep the trunk stable, we also try to make it available as a place to introduce new functionality. So, the trunk does not meet the stability requirements of our releases.

Instead, around the time of the first alpha or beta for a given major release the trunk is copied onto a release branch. major releases are releases like Kerberos 1.6 or Kerberos 1.7 as opposed to point releases like Kerberos 1.6.2. Point releases do not get their own release branch; they use the release branch of the major release of which they are a part. Release branches live in branches/krb5-x-y in subversion. For example the Kerberos 1.6 release branch is branches/krb5-1-6.

Branches, KFW and KFM

KFM and KFW do not typically create their own release branches. KFM and KFW both have separate repositories for the platform-specific parts of their code. They use one of the existing release branches in the main Kerberos repository for the core Kerberos components they use. They typically do not use a branch within their own repositories because there are a small number of people committing to the repository.

Moving changes to release branches

Only Release Engineers are permitted to make changes to release branches. Any change proposed to a release branch requires a ticket documenting the change that is marked for pullup to the release branch. See doc/procedures.txt (raw | annotated | history) for instructions on marking a ticket for pullup. See the pullup policy for the policy that a Release Engineer follows when evaluating pullups.

use trunkref not svnref