github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-11-13 17:56:10 -06:00
Code Issues 2.1k Packages Projects Releases 4 Wiki Activity

Upstream tracking version #88

New Issue
Closed
opened 2026-02-17 11:11:04 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-02-17 11:11:04 -06:00
Owner
Copy Link
Copy Source

Originally created by @mikaelkaron on GitHub (Jul 15, 2013).

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). 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 commented 2026-02-17 11:11:06 -06:00
Author
Owner
Copy Link
Copy Source

@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-02-17 11:11:06 -06:00
Author
Owner
Copy Link
Copy Source

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

@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-02-17 11:11:07 -06:00
Author
Owner
Copy Link
Copy Source

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

@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-02-17 11:11:08 -06:00
Author
Owner
Copy Link
Copy Source

@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.
@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-02-17 11:11:08 -06:00
Author
Owner
Copy Link
Copy Source

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

@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-02-17 11:11:09 -06:00
Author
Owner
Copy Link
Copy Source

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#88