Difference between revisions of "Release branches"
SamHartman (talk | contribs) m |
(Copy pullup procedures from doc/procedures.txt) |
||
| Line 1: | Line 1: | ||
| − | 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. |
+ | 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. |
+ | 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 [[Testing releases|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 <tt>branches/krb5-</tt><i>x-y</i> in subversion. For example the Kerberos 1.6 release branch is <tt>branches/krb5-1-6</tt>. |
Instead, around the time of the first [[Testing releases|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 <tt>branches/krb5-</tt><i>x-y</i> in subversion. For example the Kerberos 1.6 release branch is <tt>branches/krb5-1-6</tt>. |
||
| Line 9: | Line 9: | ||
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. |
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 |
+ | ==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. |
+ | 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 [[Release branches/Pullup policy|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 trunk, 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 the the subversion 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. |
||
Revision as of 18:35, 2 November 2011
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 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 trunk, 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 the the subversion 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.
