Open jrgriffiniii opened 2 years ago
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:
...that there be the following branches:
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:
Currently there are inconsistent and varied milestones for each core component. There should be recommended guidelines for the milestones for each of these GitHub Projects.