[Release Process] Release Cycle Planning Guidelines

Assumptions

The following assumptions are made in this guideline.

Branch distribution

• Features must target master branch
• Bug fixes must target the lowest supported branch that is affected by the bug
  • Except where the fix would require a new feature, or breaking change, to achieve
• Branch merges should be scheduled a minimum of once per week, on a Monday
• Future major version branches are only created as needed by the project life cycle

Branch	Purpose
release/A.B	Long term support branch
release/X.x	Stable release mainline branch
release/X.y	Minor version beta branch
release/X.z ²	Aux. minor version beta branch
release/N.G ²	Major version beta branch
master	Feature branch

² Secondary, as-needed, branches

The stacking logic for merges would then look like:

           release/A.B
               |
           release/X.x [default]
               |
           release/X.y
               |
           release/X.z
               |
           release/N.G
               |
             master [feature target]

Where release/A.B would be merged into release/X.x, which would then be merged into release/X.y, and so on until master.

Goals

Management of branching and release schedules is done with the following goals in mind:

• Features are (generally) always able to me merged into master
• Beta (bug-fix) branches ideally run for 14 days, but adapt to longer requirements as appropriate
• Minor releases should be minimal on features
• Next major release development branches should be able to be run on the branch stack in parallel with the leading X.y & X.z branches.

Process

Large Feature Workflow

1. Proposal
2. Core team agreement
3. Branch (target release) allocation
4. Implementation
5. Documentation

Milestone Scheduling

1. Feature freeze
   • master branched to release/x.y
   • Bug fix cycle starts
2. Bug fix cycle
   • Minor release branch
     • 2 week default minimum
     • Usually only one minor release bug-fix branch
       • Exception where advanced features are ready to land, and the leading bug-fix branch is held up from release
     • Can run concurrently to a major release branch
   • Major release branch
     • as needed
3. Release