We'd like to understand what the best practices are for dealing with numbering of releases on branches of components.
For example we have a component with versions:
1.0.0
1.0.1
1.1.0 - Included in a distribution. 6.0
2.0.0
2.0.1
2.1.0
3.0.0
3.0.1 - Included in distribution 7.0
4.0.0
The 1.1.0 code is branched to support bug fixes.
How could the 1,1,0 branch be numbered if it requires a major or minor change ?
Assuming of course that it cannot take some of the changes incorporated in 2.x or 3.x.
We have assumed that when branch the distribution, we bump the major number. Basically just to make room for minor and patch changes. Is this acceptable ?
Originally created by @colinw-calix on GitHub (Aug 26, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/218
We'd like to understand what the best practices are for dealing with numbering of releases on branches of components.
For example we have a component with versions:
1.0.0
1.0.1
1.1.0 - Included in a distribution. 6.0
2.0.0
2.0.1
2.1.0
3.0.0
3.0.1 - Included in distribution 7.0
4.0.0
The 1.1.0 code is branched to support bug fixes.
How could the 1,1,0 branch be numbered if it requires a major or minor change ?
Assuming of course that it cannot take some of the changes incorporated in 2.x or 3.x.
We have assumed that when branch the distribution, we bump the major number. Basically just to make room for minor and patch changes. Is this acceptable ?
If you're maintaining a separate branch of 1.1.0 and do a minor change, just increase the minor version.
If you want to do a major change, don't. Scratch using/supporting that branch and upgrade to another major that has it fixed.
If you really need to use that branch and really need to do a major change, consider reading through #17.
<!-- gh-comment-id:53501474 -->
@FichteFoll commented on GitHub (Aug 26, 2014):
If you're maintaining a separate branch of 1.1.0 and do a minor change, just increase the minor version.
If you want to do a major change, don't. Scratch using/supporting that branch and upgrade to another major that has it fixed.
If you _really_ need to use that branch and _really_ need to do a major change, consider reading through #17.
As a general rule, you should only back-port bug fixes to maintenance branches. The whole point of the 1.y.z branch is to support folks who haven't taken the breaking change to the 2.y.z branch. On the rare case that you feel the need to add a feature to a maintenance branch, there's always room to do so.
Unless you have further questions, please close this issue at your earliest possible convenience.
<!-- gh-comment-id:405073071 -->
@jwdonahue commented on GitHub (Jul 15, 2018):
As a general rule, you should only back-port bug fixes to maintenance branches. The whole point of the 1.y.z branch is to support folks who haven't taken the breaking change to the 2.y.z branch. On the rare case that you feel the need to add a feature to a maintenance branch, there's always room to do so.
Unless you have further questions, please close this issue at your earliest possible convenience.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @colinw-calix on GitHub (Aug 26, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/218
We'd like to understand what the best practices are for dealing with numbering of releases on branches of components.
For example we have a component with versions:
1.0.0
1.0.1
1.1.0 - Included in a distribution. 6.0
2.0.0
2.0.1
2.1.0
3.0.0
3.0.1 - Included in distribution 7.0
4.0.0
The 1.1.0 code is branched to support bug fixes.
How could the 1,1,0 branch be numbered if it requires a major or minor change ?
Assuming of course that it cannot take some of the changes incorporated in 2.x or 3.x.
We have assumed that when branch the distribution, we bump the major number. Basically just to make room for minor and patch changes. Is this acceptable ?
@FichteFoll commented on GitHub (Aug 26, 2014):
If you're maintaining a separate branch of 1.1.0 and do a minor change, just increase the minor version.
If you want to do a major change, don't. Scratch using/supporting that branch and upgrade to another major that has it fixed.
If you really need to use that branch and really need to do a major change, consider reading through #17.
@jwdonahue commented on GitHub (Jul 15, 2018):
As a general rule, you should only back-port bug fixes to maintenance branches. The whole point of the 1.y.z branch is to support folks who haven't taken the breaking change to the 2.y.z branch. On the rare case that you feel the need to add a feature to a maintenance branch, there's always room to do so.
Unless you have further questions, please close this issue at your earliest possible convenience.
@Kcstroman8 commented on GitHub (Dec 4, 2024):
Trying to program my nerm minor v two help