[GH-ISSUE #218] How to deal with major/minor changes on a branched release. #1880

New Issue

GiteaMirror · 2026-04-20T09:37:57-05:00

GiteaMirror commented

2026-04-20 09:37:57 -05:00

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 ?

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 ?

GiteaMirror closed this issue

2026-04-20 09:37:57 -05:00

GiteaMirror commented

2026-04-20 09:37:59 -05:00

@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.

@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.

GiteaMirror commented

2026-04-20 09:37:59 -05:00

@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.

@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.

GiteaMirror commented

2026-04-20 09:38:00 -05:00

@Kcstroman8 commented on GitHub (Dec 4, 2024):

Trying to program my nerm minor v two help

@Kcstroman8 commented on GitHub (Dec 4, 2024): Trying to program my nerm minor v two help

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1880