Non-linear developement #183

New Issue

2026-02-17T11:31:04-06:00

GiteaMirror commented

2026-02-17 11:31:04 -06:00

Originally created by @Ericson2314 on GitHub (Jun 29, 2015).

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). 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-02-17 11:31:05 -06:00

GiteaMirror commented

2026-02-17 11:31:06 -06: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-02-17 11:31:07 -06: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-02-17 11:31:08 -06: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.