mirror of
https://github.com/semver/semver.git
synced 2026-03-22 22:20:28 -05:00
Version for dependencies patched by vendor #425
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#425
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 @sjackman on GitHub (Jul 13, 2020).
I have forked a dependency to make a fix on my fork, and that patched version is a dependency of my other project. What should the version number of this patched dependency be? The upstream version is
1.2.3. I suggest that my patched version is1.2.3.sjackman.0, and the next patched version would be1.2.3.sjackman.1. Thoughts?@ljharb commented on GitHub (Jul 13, 2020):
A fork is a different project that should have a different name, and thus has no required relationship to the original project's version number.
@sjackman commented on GitHub (Jul 13, 2020):
A good suggestion. In the case of GitHub, the user/repo pair can be used:
sjackman/projectversion1.2.3. It would be nice if the version number of my forked project could somehow reflect the version number of the upstream project. If the upstream version is1.2.3, I'd prefer to tag my version1.2.3.1rather than1.2.4, which would be confusing when the upstream project releases their1.2.4.@sjackman commented on GitHub (Jul 13, 2020):
Feel free to close this issue as beyond scope (won't fix). I wanted to know if there was an existing best practice.
@ljharb commented on GitHub (Jul 13, 2020):
My personal recommendation here is to use a scope - ie,
@sjackman/project, and to mirror the version numbers such that for everyx.y.zrelease ofproject, you release anx.y.zof@sjackman/project. This of course depends on what you're patching in - the alternative is, if your delta is a patch, yours would bex.y.z+1, if a minor,x.y+1.z, etc - that way your fork always matches "what the real one would be if it suddenly released with your change".@sjackman commented on GitHub (Jul 13, 2020):
Is this
@"scope" a feature of SemVer? I don't see it described at https://semver.orgIf I were to tag my patched version
1.2.4, when upstream eventually tags a different version1.2.4, when Igit fetch upstream --tags, now these two tags conflict, that is to say, they point at different Git commit SHA-1. My tags will need to be different (say1.2.3.sjackman.0) or in a different namespace (saysjackman/1.2.4) than upstream's tags. Perhaps that's what you meant by a "scope".@ljharb commented on GitHub (Jul 14, 2020):
Oh, sorry, I assumed this was npm :-) disregard the scope stuff if you're not using npm.
Yes, I would assume that the versions would always point to different SHAs - your fork is a completely distinct project, that only has a conceptual link to the original. As such, commit SHAs likely will never match.
@sjackman commented on GitHub (Jul 14, 2020):
Every tag up to the point of forking will agree perfectly, so
commit SHAs likely will never matchis not universally true. The two projects share a common ancestry, and the conceptual link between these projects is rather important.I do believe my question is outside the scope of SemVer though, and we're beginning to talk past each other.
@ljharb commented on GitHub (Jul 14, 2020):
I think you’re right, yes :-) in short, i think the conceptual link, while critical, belongs in prose and not in the version number.
@sjackman commented on GitHub (Jul 14, 2020):
Thanks for the chat, Jordan!