mirror of
https://github.com/semver/semver.git
synced 2026-07-11 09:43:20 -05:00
[GH-ISSUE #138] Upstream tracking version #1821
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1821
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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-aand the currently released version is1.2.3. I'd like to make some modifications topackage-aand simply indicate that my version is upstream version1.2.3with 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 bygit describeto signify no-of changes since tag. So if I have 10 changes since I tagged1.0.0I can rungit describeto get something like1.0.0-10-1234567(last part is the short SHA to my commit), and it feels a bit weird that1.0.0-10<1.0.0(even if I understand the logic)@mikaelkaron commented on GitHub (Jul 15, 2013):
And I see that #106 has already talked about
git describe@EddieGarmon commented on GitHub (Jul 15, 2013):
To follow SemVer semantics, and to track an up stream package, I would do the following:
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.
@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:
maven-findbugs-plugin v?????)
Thanks in advance,
Dale
On 15 July 2013 12:26, Eddie Garmon notifications@github.com wrote:
@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
@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:
@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.