Managing Branches in GitHub

NOTE: This page is an early draft. Pay it no attention until this notice is removed.

Introduction

Following the release of perfSONAR 4.1, the development team adopted a more-formal scheme for version control during development. There are central tenets:

• Any change is to be developed along a branch named after the release for which it is intended.
• Once the code on the branch is ready to be released, the branch is locked and the release is done.
• Changes made in the branch are merged into branches for later releases.

Making a Change

1. Select the release for which the change is targeted. This will depend on the nature of the change. For example, a new major feature not present in version 9.0 would be targeted for 9.1.

2. Open an issue to cover the change and set the release to correspond with the one selected above. Note the number of the new issue. 9999 will be used as an example.

3. Check out the 9.1 branch.

4. Create a new branch from 9.1 called issue-9999.

5. Check out the issue-9999 branch.

6. Develop, commit and push changes.

7. Submit a pull request to merge issue-9999 into 9.1. Once the change is pulled, the issue-9999 branch will be deleted.

Release Procedures

Locking a Branch

Following a release, the branch being released is considered closed.

• 9.0 (Paradigm Shift release)

  • Close the 9.0 branch (see above)
  • Create 9.0.0.1 (Fast-Track Patch)
  • Create 9.0.1 (Bug Fix / Minor Enhancement)
  • Create 9.1 (Major Feature)
  • Create 10 (Paradigm Shift)
  • Pull 9.0 into master and tag it release-9.0

• 9.0.0.1 (Fast-Track Patch)

  • Lock the 9.0.0.1 branch (see above)
  • Create 9.0.0.2 (Fast-Track Patch)
  • Pull 9.0.0.1 into master and tag it release-9.0.0.1

• 9.0.1 (Bug Fix / Minor Enhancement)

  • Create 9.0.1.1 (Fast-Track Patch)
  • Pull 9.0.1 into master and tag it release-9.0.1