Release branches

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

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

Instead, around the time of the first alpha or beta for a given major release, a release branch is created from the master 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 are named krb5-x.y in git. For example the Kerberos 1.6 release branch is 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 the pullup policy for the policy that a Release Engineer follows when evaluating pullups.

No changes should be committed to a release branch except by the release engineer or other approved person. Changes to be included on the release branch must first be committed to the master branch, and must have an associated RT ticket. This ticket should have its "target_version" keyword set to the release that the change is targeted at, and should have the "pullup" tag set. This ticket should clearly document the changes that are to be pulled up to the release branch; the recommended way to do this is to ensure that the git commit operations corresponding to the changes have automatically updated the ticket -- see the following section. The release engineer will pull up the change to the release branch and set the "version_fixed" keyword on the ticket.