[GH-ISSUE #259] Non-linear developement #6173

New Issue

GiteaMirror · 2026-06-17T04:48:36-05:00

GiteaMirror commented

2026-06-17 04:48:36 -05:00

Originally created by @Ericson2314 on GitHub (Jun 29, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/259

Larger projects usually maintain multiple branches of releases. This is done to offer both stability and flexibility. An example of this would be backporting a security fix to an old release.

It is possible to version the project so that the comparability between releases obeys semver's requirements--in other words so the project can be consumed as if it were versioned with semver. However it is not clear how one should go about doing this. For example:

Assume 1.1.0 and 1.2.0, 2.0.0-alpha, 2.0.0 are released. An bug is found affecting all versions. Should I release 1.1.1? Can I release 2.0.0-alpha2?

Originally created by @Ericson2314 on GitHub (Jun 29, 2015). Original GitHub issue: https://github.com/semver/semver/issues/259 Larger projects usually maintain multiple branches of releases. This is done to offer both stability and flexibility. An example of this would be backporting a security fix to an old release. It is possible to version the project so that the comparability between releases obeys semver's requirements--in other words so the project can be consumed as if it were versioned with semver. However it is not clear how one should go about doing this. For example: Assume `1.1.0` and `1.2.0`, `2.0.0-alpha`, `2.0.0` are released. An bug is found affecting all versions. Should I release `1.1.1`? Can I release `2.0.0-alpha2`?

GiteaMirror closed this issue

2026-06-17 04:48:37 -05:00

GiteaMirror commented

2026-06-17 04:48:39 -05:00

@FichteFoll commented on GitHub (Jun 29, 2015):

Depends on the adaptation of that software. If there is a need to support minor versions, then release 1.1.1, 1.2.1 and 2.0.1. If there is a need to support major versions, release 1.2.1 and 2.0.1. Otherwise, only release 2.0.1. (By "need" I mean if others are restricting your dependency to a minor version because of incompatibilities with the next minor release (shouldn't be the case if you correctly follow sever) or if the update process is complicated.)

Pre-releases do not need fix releases since 2.0.0 comes immediately after 2.0.0-alpha already (assuming this is the latest pre-release). People shouldn't be using pre-releases longer than they need to, i.e. when the next stable is released.

@FichteFoll commented on GitHub (Jun 29, 2015): Depends on the adaptation of that software. If there is a need to support minor versions, then release `1.1.1`, `1.2.1` and `2.0.1`. If there is a need to support major versions, release `1.2.1` and `2.0.1`. Otherwise, only release `2.0.1`. (By "need" I mean if others are restricting your dependency to a minor version because of incompatibilities with the next minor release (shouldn't be the case if you correctly follow sever) or if the update process is complicated.) Pre-releases do not need fix releases since 2.0.0 comes immediately after 2.0.0-alpha already (assuming this is the latest pre-release). People shouldn't be using pre-releases longer than they need to, i.e. when the next stable is released.

GiteaMirror commented

2026-06-17 04:48:41 -05:00

@Ericson2314 commented on GitHub (Jun 29, 2015):

But since there are no breaking changes between versions equal up to minor release, why should anyone support any but the last?

@Ericson2314 commented on GitHub (Jun 29, 2015): But since there are no breaking changes between versions equal up to minor release, why should anyone support any but the last?

GiteaMirror commented

2026-06-17 04:48:42 -05:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@Ericson2314

But since there are no breaking changes between versions equal up to minor release, why should anyone support any but the last?

I don't understand that question. Do you still need an answer? If not, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @Ericson2314 >But since there are no breaking changes between versions equal up to minor release, why should anyone support any but the last? I don't understand that question. Do you still need an answer? If not, please close this issue at your earliest possible convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6173