[GH-ISSUE #138] Upstream tracking version #6078

New Issue

GiteaMirror · 2026-06-17T04:30:46-05:00

GiteaMirror commented

2026-06-17 04:30:46 -05:00

Originally created by @mikaelkaron on GitHub (Jul 15, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/138

I'm trying to track the upstream version of another project while still staying consistent with versioning.

Say for instance I'm tracking package-a and the currently released version is 1.2.3. I'd like to make some modifications to package-a and simply indicate that my version is upstream version 1.2.3 with my local patches.

In ubuntu I'd probably call the package 1.2.3-ubuntu1, but according to the spec - should be used to track pre-releases (like -alpha).

So I guess I'm wondering what I can do to achieve tracking_an_upstream_version with as little pain as possible.

Not that it's important for this ticket, but - versions are actually used internally by git describe to signify no-of changes since tag. So if I have 10 changes since I tagged 1.0.0 I can run git describe to get something like 1.0.0-10-1234567 (last part is the short SHA to my commit), and it feels a bit weird that 1.0.0-10 < 1.0.0 (even if I understand the logic)

Originally created by @mikaelkaron on GitHub (Jul 15, 2013). Original GitHub issue: https://github.com/semver/semver/issues/138 I'm trying to track the upstream version of another project while still staying consistent with versioning. Say for instance I'm tracking `package-a` and the currently released version is `1.2.3`. I'd like to make some modifications to `package-a` and simply indicate that my version is upstream version `1.2.3` with my local patches. In ubuntu I'd probably call the package `1.2.3-ubuntu1`, but according to the spec `-` should be used to track pre-releases (like `-alpha`). So I guess I'm wondering what I can do to achieve _tracking_an_upstream_version_ with as little pain as possible. --- Not that it's important for this ticket, but `-` versions are actually used internally by `git describe` to signify no-of changes since tag. So if I have 10 changes since I tagged `1.0.0` I can run `git describe` to get something like `1.0.0-10-1234567` (last part is the short SHA to my commit), and it feels a bit weird that `1.0.0-10` < `1.0.0` (even if I understand the logic)

GiteaMirror closed this issue

2026-06-17 04:30:47 -05:00

GiteaMirror commented

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

@mikaelkaron commented on GitHub (Jul 15, 2013):

And I see that #106 has already talked about git describe

@mikaelkaron commented on GitHub (Jul 15, 2013): And I see that #106 has already talked about `git describe`

GiteaMirror commented

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

@EddieGarmon commented on GitHub (Jul 15, 2013):

To follow SemVer semantics, and to track an up stream package, I would do the following:

appropriate version my edits
mark it as prerelease
embed the upstream version in the build metadata, optionally you could do this in the prerelease

so 1.2.3 upstream with a patch could be 1.2.4-my.patch+1.2.3
and 1.2.3 with a minor api addition would be 1.3.0-my.additions+1.2.3
and a breaking change would be 2.0.0-my.break+1.2.3

the choice of prerelease flag should probably have value to you.

also, if you are not planning to push you edits back upstream, I would suggest making a name change on the package so that you don't get confused with the next upstream releases.

@EddieGarmon commented on GitHub (Jul 15, 2013): To follow SemVer semantics, and to track an up stream package, I would do the following: 1. appropriate version my edits 2. mark it as prerelease 3. embed the upstream version in the build metadata, optionally you could do this in the prerelease so 1.2.3 upstream with a patch could be 1.2.4-my.patch+1.2.3 and 1.2.3 with a minor api addition would be 1.3.0-my.additions+1.2.3 and a breaking change would be 2.0.0-my.break+1.2.3 the choice of prerelease flag should probably have value to you. also, if you are not planning to push you edits back upstream, I would suggest making a name change on the package so that you don't get confused with the next upstream releases.

GiteaMirror commented

2026-06-17 04:30:49 -05:00

@dwijnand commented on GitHub (Jul 15, 2013):

I'm not the OP, but I like your solution for the original use-case.

However, what if the case were something like:

the upstream program is a code analysing tool (eg. Findbugs v2.0)
my program is a build tool plugin for that tool (eg.
maven-findbugs-plugin v?????)

Thanks in advance,
Dale

On 15 July 2013 12:26, Eddie Garmon notifications@github.com wrote:

To follow SemVer semantics, and to track an up stream package, I would do
the following:

appropriate version my edits

mark it as prerelease

embed the upstream version in the build metadata, optionally you
could do this in the prerelease

so 1.2.3 upstream with a patch could be 1.2.4-my.patch+1.2.3
and 1.2.3 with a minor api addition would be 1.3.0-my.additions+1.2.3
and a breaking change would be 2.0.0-my.break+1.2.3

the choice of prerelease flag should probably have value to you.

also, if you are not planning to push you edits back upstream, I would
suggest making a name change on the package so that you don't get confused
with the next upstream releases.

—
Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/138#issuecomment-20963799
.

@dwijnand commented on GitHub (Jul 15, 2013): I'm not the OP, but I like your solution for the original use-case. However, what if the case were something like: - the upstream program is a code analysing tool (eg. Findbugs v2.0) - my program is a build tool plugin for that tool (eg. maven-findbugs-plugin v?????) Thanks in advance, Dale On 15 July 2013 12:26, Eddie Garmon notifications@github.com wrote: > To follow SemVer semantics, and to track an up stream package, I would do > the following: > 1. appropriate version my edits > 2. mark it as prerelease > 3. embed the upstream version in the build metadata, optionally you > could do this in the prerelease > > so 1.2.3 upstream with a patch could be 1.2.4-my.patch+1.2.3 > and 1.2.3 with a minor api addition would be 1.3.0-my.additions+1.2.3 > and a breaking change would be 2.0.0-my.break+1.2.3 > > the choice of prerelease flag should probably have value to you. > > also, if you are not planning to push you edits back upstream, I would > suggest making a name change on the package so that you don't get confused > with the next upstream releases. > > — > Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/138#issuecomment-20963799 > .

GiteaMirror commented

2026-06-17 04:30:49 -05:00

@EddieGarmon commented on GitHub (Jul 15, 2013):

@dwijnand in your case, you are not editing the Findbugs package as @mikaelkaron suggests he would do, therefor your plugin version should be 100% independent of the Findbugs version.

Again, here is where the openness of the build metadata shines

my.plugin 1.2.3+Findbugs.2.0
my.plugin 1.2.4+Findbugs.2.0
my.plugin 2.0.0+Findbugs.2.0
etc.

@EddieGarmon commented on GitHub (Jul 15, 2013): @dwijnand in your case, you are not editing the Findbugs package as @mikaelkaron suggests he would do, therefor your plugin version should be 100% independent of the Findbugs version. Again, here is where the openness of the build metadata shines 1. my.plugin 1.2.3+Findbugs.2.0 2. my.plugin 1.2.4+Findbugs.2.0 3. my.plugin 2.0.0+Findbugs.2.0 4. etc.

GiteaMirror commented

2026-06-17 04:30:50 -05:00

@dwijnand commented on GitHub (Jul 15, 2013):

OK, thanks for the suggestions.

Dale

On 15 July 2013 16:53, Eddie Garmon notifications@github.com wrote:

@dwijnand https://github.com/dwijnand in your case, you are not editing
the Findbugs package as @mikaelkaron https://github.com/mikaelkaronsuggests he would do, therefor your plugin version should be 100%
independent of the Findbugs version.

Again, here is where the openness of the build metadata shines

my.plugin 1.2.3+Findbugs.2.0

my.plugin 1.2.4+Findbugs.2.0

my.plugin 2.0.0+Findbugs.2.0

etc.

—
Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/138#issuecomment-20979276
.

@dwijnand commented on GitHub (Jul 15, 2013): OK, thanks for the suggestions. Dale On 15 July 2013 16:53, Eddie Garmon notifications@github.com wrote: > @dwijnand https://github.com/dwijnand in your case, you are not editing > the Findbugs package as @mikaelkaron https://github.com/mikaelkaronsuggests he would do, therefor your plugin version should be 100% > independent of the Findbugs version. > > Again, here is where the openness of the build metadata shines > 1. my.plugin 1.2.3+Findbugs.2.0 > 2. my.plugin 1.2.4+Findbugs.2.0 > 3. my.plugin 2.0.0+Findbugs.2.0 > 4. etc. > > — > Reply to this email directly or view it on GitHubhttps://github.com/mojombo/semver/issues/138#issuecomment-20979276 > .

GiteaMirror commented

2026-06-17 04:30:52 -05:00

@mikaelkaron commented on GitHub (Jul 17, 2013):

Thanks for all the input! Closing now as I think this answers the question well. thanks @EddieGarmon for all the help.

@mikaelkaron commented on GitHub (Jul 17, 2013): Thanks for all the input! Closing now as I think this answers the question well. thanks @EddieGarmon for all the help.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6078