[GH-ISSUE #518] How to tag official releases with added patch set #5501

New Issue

GiteaMirror · 2026-06-15T11:57:10-05:00

GiteaMirror commented

2026-06-15 11:57:10 -05:00

Originally created by @sylr on GitHub (May 27, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/518

Hi,

I am maintaining a number of patch sets for projects that refused to merge them. I regularly rebase these patch sets on top of the new releases of the official releases.

Say software A releases version v2.9.2 and that I apply my patch set on top of v2.9.2. I previously was tagging my releases of the A software v2.9.2+sylr.x where x is a version of my patch set.

Reading more about semantic versioning I learnt that the +xxxx suffix designates the build metadata and that the precedence does not apply to that suffix so I am wondering what do you recommend to use in this case if not +xxxxx.

Regards.

Originally created by @sylr on GitHub (May 27, 2019). Original GitHub issue: https://github.com/semver/semver/issues/518 Hi, I am maintaining a number of patch sets for projects that refused to merge them. I regularly rebase these patch sets on top of the new releases of the official releases. Say software `A` releases version `v2.9.2` and that I apply my patch set on top of `v2.9.2`. I previously was tagging my releases of the `A` software `v2.9.2+sylr.x` where `x` is a version of my patch set. Reading more about semantic versioning I learnt that the `+xxxx` suffix designates the build metadata and that the precedence does not apply to that suffix so I am wondering what do you recommend to use in this case if not `+xxxxx`. Regards.

GiteaMirror added the question label 2026-06-15 11:57:10 -05:00

GiteaMirror closed this issue

2026-06-15 11:57:11 -05:00

GiteaMirror commented

2026-06-15 11:57:13 -05:00

@runeimp commented on GitHub (May 28, 2019):

@sylr There is no post release version semantics that this project acknowledges at this point. At least as far as I know. Though if you scan though the open and closed issues you will see many discussions regarding this sort of thing.

@runeimp commented on GitHub (May 28, 2019): @sylr There is no post release version semantics that this project acknowledges at this point. At least as far as I know. Though if you scan though the open and closed issues you will see many discussions regarding this sort of thing.

GiteaMirror commented

2026-06-15 11:57:14 -05:00

@klehelley commented on GitHub (May 28, 2019):

I take it that your fork keeps the same name as the project it is derived from, and that project uses SemVer. Am I right? If that's the case, the simplest way I see to handle your situation would be for your fork to actually use a different name, and to not constraint yourself to follow exactly the versions used in upstream.

Of course, in that case you will need to clearly document what version of A the version of A-patched you release is based on. Also, if your patch goes beyond bug fixing the version numbers between the two projects may grow very different with time.

Example scenario:

A-patched v1.1.0 is based on A v1.1.0
A-patched v1.1.1 is based on A v1.1.1 (bugfix in upstream)
A-patched v1.2.0 is based on A v1.1.1 (new feature in fork)
A-patched v1.3.0 is based on A v1.2.0 (new feature in upstream)
A-patched v1.3.1 is based on A v1.2.0 (bugfix in fork)
A-patched v1.3.2 is based on A v1.2.5 (several bugfixes in upstream, but the fork has not been systematically synchronized)
A-patched v2.0.0 is based on A v2.0.0 (breaking changes in upstream, but maybe also in fork-specific code)

@klehelley commented on GitHub (May 28, 2019): I take it that your fork keeps the same name as the project it is derived from, and that project uses SemVer. Am I right? If that's the case, the simplest way I see to handle your situation would be for your fork to actually use a different name, and to not constraint yourself to follow exactly the versions used in upstream. Of course, in that case you will need to clearly document what version of `A` the version of `A-patched` you release is based on. Also, if your patch goes beyond bug fixing the version numbers between the two projects may grow very different with time. Example scenario: * `A-patched v1.1.0` is based on `A v1.1.0` * `A-patched v1.1.1` is based on `A v1.1.1` (bugfix in upstream) * `A-patched v1.2.0` is based on `A v1.1.1` (new feature in fork) * `A-patched v1.3.0` is based on `A v1.2.0` (new feature in upstream) * `A-patched v1.3.1` is based on `A v1.2.0` (bugfix in fork) * `A-patched v1.3.2` is based on `A v1.2.5` (several bugfixes in upstream, but the fork has not been systematically synchronized) * `A-patched v2.0.0` is based on `A v2.0.0` (breaking changes in upstream, but maybe also in fork-specific code)

GiteaMirror commented

2026-06-15 11:57:14 -05:00

@sylr commented on GitHub (May 28, 2019):

I take it that your fork keeps the same name as the project it is derived from, and that project uses SemVer.

Absolutely.

I maintain soft forks, I want to stay as close as possible to the initial project so I'm not comfortable with changing the name of the project.

@sylr commented on GitHub (May 28, 2019): > I take it that your fork keeps the same name as the project it is derived from, and that project uses SemVer. Absolutely. I maintain soft forks, I want to stay as close as possible to the initial project so I'm not comfortable with changing the name of the project.

GiteaMirror commented

2026-06-15 11:57:15 -05:00

@jwdonahue commented on GitHub (Aug 10, 2019):

I maintain soft forks, I want to stay as close as possible to the initial project so I'm not comfortable with changing the name of the project.

In some circles, that would be considered fraud. If you are not the publisher of A, then don't pretend to be A.

@jwdonahue commented on GitHub (Aug 10, 2019): > I maintain soft forks, I want to stay as close as possible to the initial project so I'm not comfortable with changing the name of the project. In some circles, that would be considered fraud. If you are not the publisher of A, then don't pretend to be A.

GiteaMirror commented

2026-06-15 11:57:16 -05:00

@grv87 commented on GitHub (Aug 23, 2019):

What' s the difference between your fork and original project? Are your changes backward-compatible? Can your project be used as a replacement for original?
If yes then, IMO, your original approach with build metadata is correct.

If no then @jwdonahue and @klehelley are right, you definitely should rename your project.
You don't tell specifics what is your project. But as examples, in Maven you usually change just the group and don't touch project name. NPM has scopes.

@grv87 commented on GitHub (Aug 23, 2019): What' s the difference between your fork and original project? Are your changes backward-compatible? Can your project be used as a replacement for original? If yes then, IMO, your original approach with build metadata is correct. If no then @jwdonahue and @klehelley are right, you definitely should rename your project. You don't tell specifics what is your project. But as examples, in Maven you usually change just the group and don't touch project name. NPM has scopes.

GiteaMirror commented

2026-06-15 11:57:17 -05:00

@mwgamble commented on GitHub (Apr 13, 2022):

In some circles, that would be considered fraud. If you are not the publisher of A, then don't pretend to be A.

This is a bit over the top. Sometimes an organisation needs to maintain an internal fork of a piece of software for various reasons. In this case, it would be nice to have a supported versioning strategy for these kinds of releases.

@mwgamble commented on GitHub (Apr 13, 2022): > In some circles, that would be considered fraud. If you are not the publisher of A, then don't pretend to be A. This is a bit over the top. Sometimes an organisation needs to maintain an internal fork of a piece of software for various reasons. In this case, it would be nice to have a supported versioning strategy for these kinds of releases.

GiteaMirror commented

2026-06-15 11:57:18 -05:00

@jwdonahue commented on GitHub (Dec 22, 2023):

@mwgamble

Sometimes an organisation needs to maintain an internal fork of a piece of software for various reasons. In this case, it would be nice to have a supported versioning strategy for these kinds of releases

That would not be a violation of most of the OSS licenses I am aware of, but redistributing it under the same name is often a violation of copyright or trademark law, if not explicitly banned in the license. As @grv87 points out, it's often acceptable to change the prefix of the package name in cases like this.

@jwdonahue commented on GitHub (Dec 22, 2023): @mwgamble > Sometimes an organisation needs to maintain an internal fork of a piece of software for various reasons. In this case, it would be nice to have a supported versioning strategy for these kinds of releases That would not be a violation of most of the OSS licenses I am aware of, but redistributing it under the same name is often a violation of copyright or trademark law, if not explicitly banned in the license. As @grv87 points out, it's often acceptable to change the prefix of the package name in cases like this.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5501