Evaluating branch naming practices which have been followed by other practices, there seems to be the following pattern which has emerged:

- 1.x-stable
- 2.x-stable
- 2.1-stable
- 3.0.0-release

What I shall propose is that, for cases such as one with three major releases:

• 3.0.0
• 2.2.1
• 1.1.2

...that there be the following branches:

• 1.1-stable
• 2.2-stable
• 3.0-stable

Please note that minor releases should ensure that only backwards-compatible changes are introduced:

MINOR version when you add functionality in a backwards compatible manner, and

Hence, 1.0-stable would be released for the initial 1.0.0 version, and then track each successive change until 1.1.0 is released. Once 1.1.0 is released, the branch 1.0-stable should be deleted, and 1.1-stable should be created. Henceforth, 1.1-stable should contain all of the changes for the next patch release.

Milestones should then follow this pattern, with each milestone tracking defined releases:

• 1.1.2 (Closed Milestone)
• 1.1.3 (Open Milestone)
• 2.2.1 (Closed Milestone)
• 2.2.2 (Open Milestone)