github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 05:12:48 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

point 11 of semver 2.0.0 specification (definition of "precedence") is meaningless #281

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

Originally created by @coproc on GitHub (Jun 2, 2017).

Point 11 of semver 2.0.0 specification (definition of "precedence") is superfluous and does not add anything useful. The "precedence" as currently defined in semver only tells you, when you can put a symbol '<' between two versions, but does not give any meaning to it. From 'v1 < v2' you cannot imply anything - except that feature_set(v1) <= feature_set(v2), which is not very useful. Even if 'v1 < v2' holds (according to the current defintion), it could be that v1 was released after v2 and that not all commits of v1 are part of v2 (think of a maintenance release 2.1.2 for a bug found in 2.1.1 that is still existing in the already released 3.0.0). So I think that point 11 of the current specification can and should be discarded.

Btw: What I would consider helpful is a definition of precedence that tells me if all commits (including bug fixes) of one version are incorporated into another version. But this probably goes beyond the capabilities of semantic versioning.

Originally created by @coproc on GitHub (Jun 2, 2017). Point 11 of semver 2.0.0 specification (definition of "precedence") is superfluous and does not add anything useful. The "precedence" as currently defined in semver only tells you, when you can put a symbol '<' between two versions, but does not give any meaning to it. From 'v1 < v2' you cannot imply anything - except that feature_set(v1) <= feature_set(v2), which is not very useful. Even if 'v1 < v2' holds (according to the current defintion), it could be that v1 was released after v2 and that not all commits of v1 are part of v2 (think of a maintenance release 2.1.2 for a bug found in 2.1.1 that is still existing in the already released 3.0.0). So I think that point 11 of the current specification can and should be discarded. Btw: What I would consider helpful is a definition of precedence that tells me if all commits (including bug fixes) of one version are incorporated into another version. But this probably goes beyond the capabilities of semantic versioning.
GiteaMirror commented 2026-02-17 11:45:14 -06:00
Author
Owner
Copy Link

@FichteFoll commented on GitHub (Jun 2, 2017):

The version number has nothing to do with how this version's code base was constructed. It could be one commit from the "last" release or a hundred. It could also be not commit at all and just be local changes because of a packaging error or similar. A new minor version release could not contain commits of the last minor's patch release, and that could also have been release after a version with higher precedence. Think of Python release versions.

'v1 < v2' helps package managers (and you) determine which version to install, because ideally you want the "largest", potentially under a few conditions.

@FichteFoll commented on GitHub (Jun 2, 2017): The version number has nothing to do with how this version's code base was constructed. It could be one commit from the "last" release or a hundred. It could also be not commit at all and just be local changes because of a packaging error or similar. A new minor version release could not contain commits of the last minor's patch release, and that could also have been release after a version with higher precedence. Think of Python release versions. 'v1 < v2' helps package managers (and you) determine which version to install, because ideally you want the "largest", potentially under a few conditions.
GiteaMirror commented 2026-02-17 11:45:15 -06:00
Author
Owner
Copy Link

@coproc commented on GitHub (Jun 10, 2017):

So in your comment you are trying to give a meaning to "precedence" as defined in semantic versioning 2.0.0. I still see these issues:

  1. The meaning of "precedence" in the context of semantic versioning should be defined by semantic versioning itself (and not by, e.g., looking how Python versioning is done)
  2. Also your definition of the meaning of precedence ("ideally you want to install the maximal version - maximal regarding the defined '<' operator") is very vague - and definitely not valid without addtional conditions.
  3. Is there any example of explicit usage of the precedence definition, i.e. the '<'-operator between versions? Is any project explicitely referring to it?
@coproc commented on GitHub (Jun 10, 2017): So in your comment you are trying to give a meaning to "precedence" as defined in semantic versioning 2.0.0. I still see these issues: 1. The meaning of "precedence" in the context of semantic versioning should be defined by semantic versioning itself (and not by, e.g., looking how Python versioning is done) 2. Also your definition of the meaning of precedence ("ideally you want to install the maximal version - maximal regarding the defined '<' operator") is very vague - and definitely not valid without addtional conditions. 3. Is there any example of explicit usage of the precedence definition, i.e. the '<'-operator between versions? Is any project explicitely referring to it?
GiteaMirror commented 2026-02-17 11:45:16 -06:00
Author
Owner
Copy Link

@FichteFoll commented on GitHub (Jun 10, 2017):

  1. My explanation is solely based on the spec. I was merely giving an example of something that behaves like this.
  2. I don't see how it is vague. What do you want to infer from precedence? Please elaborate.
  3. I made an implementation of SemVer in Python a while ago, but that refers to semver 2.0.0-rc.2, which didn't disallow precedence between build metadata. Thus, I can't really recommend it.
@FichteFoll commented on GitHub (Jun 10, 2017): 1. My explanation is solely based on the spec. I was merely giving an example of something that behaves like this. 2. I don't see how it is vague. What do *you* want to infer from precedence? Please elaborate. 3. I made an implementation of SemVer in Python a while ago, but that refers to semver 2.0.0-rc.2, which didn't disallow precedence between build metadata. Thus, I can't really recommend it.
GiteaMirror commented 2026-02-17 11:45:17 -06:00
Author
Owner
Copy Link

@olivier-spinelli commented on GitHub (Nov 6, 2017):

An implementation of SemVer 2.0 in C# that uses operator overloads:
https://github.com/SimpleGitVersion/CSemVer-Net/blob/master/CSemVer/SVersion.cs
And may be this could interest you if you are dealing with precedence: http://csemver.org/

@olivier-spinelli commented on GitHub (Nov 6, 2017): An implementation of SemVer 2.0 in C# that uses operator overloads: https://github.com/SimpleGitVersion/CSemVer-Net/blob/master/CSemVer/SVersion.cs And may be this could interest you if you are dealing with precedence: http://csemver.org/
GiteaMirror commented 2026-02-17 11:45:19 -06:00
Author
Owner
Copy Link

@jwdonahue commented on GitHub (Nov 28, 2017):

@coproc, I feel your pain. While the spec is a little weak in the area of version selectors, it does define a complete sort order that has been used many times to write actual code. I can attest to the fact that there are ~10K users in the world, using tooling that I helped create, which employs SemVer and adds range selection capability, including the < operation (defined using set notation) and has among its critical requirements, that it adhere to version precedents defined in SemVer v2.0.0. We also had to thread the needle between that spec and current/planned NuGet versioning/range selection semantics and syntax.

The problem of encoding feature/bug-fix lists in a simple five part version string is intractable. You haven't even begun to express the complexities surrounding semantic versioning, until you start thinking about thousands of products, spread across thousands of branches, combining into pull-request builds, special test-only versions, A/B flight tests and weekly releases of all of the above (daily releases for many), multiplied by ~10K developer's snow-flakes.

The SemVer spec, defines a small, tractable piece of the overall dev/sys-ops problems related to tracking the many-to-many relationships between tens of thousands of components. The inter/intra-dependency graph problem is well beyond the scope of the SemVer specification. I argue that a well formed SemVer should be the key to the root of that graph. Where and how that graph is implemented is a problem that has yet to be adequately solved.

I vote this issue be closed.

@jwdonahue commented on GitHub (Nov 28, 2017): @coproc, I feel your pain. While the spec is a little weak in the area of version selectors, it does define a complete sort order that has been used many times to write actual code. I can attest to the fact that there are ~10K users in the world, using tooling that I helped create, which employs SemVer and adds range selection capability, including the < operation (defined using set notation) and has among its critical requirements, that it adhere to version precedents defined in SemVer v2.0.0. We also had to thread the needle between that spec and current/planned NuGet versioning/range selection semantics and syntax. The problem of encoding feature/bug-fix lists in a simple five part version string is intractable. You haven't even begun to express the complexities surrounding semantic versioning, until you start thinking about thousands of products, spread across thousands of branches, combining into pull-request builds, special test-only versions, A/B flight tests and weekly releases of all of the above (daily releases for many), multiplied by ~10K developer's snow-flakes. The SemVer spec, defines a small, tractable piece of the overall dev/sys-ops problems related to tracking the many-to-many relationships between tens of thousands of components. The inter/intra-dependency graph problem is well beyond the scope of the SemVer specification. I argue that a well formed SemVer should be the key to the root of that graph. Where and how that graph is implemented is a problem that has yet to be adequately solved. I vote this issue be closed.
GiteaMirror commented 2026-02-17 11:45:19 -06:00
Author
Owner
Copy Link

@coproc commented on GitHub (Nov 28, 2017):

ok,
I see your point. Although the defined sort order does not carry much
information in the (very) general case, it is useful in most cases.
Please close the issue.
Wolfgang
On Tue 28/11/17 11:24 , Joseph Donahue notifications@github.com
sent:
@coproc [1], I feel your pain. While the spec is a little weak in
the area of version selectors, it does define a complete sort order
that has been used many times to write actual code. I can attest to
the fact that there are ~10K users in the world, using tooling that I
helped create, which employs SemVer and adds range selection
capability, including the < operation (defined using set notation) and
has among its critical requirements, that it adhere to version
precedents defined in SemVer v2.0.0. We also had to thread the needle
between that spec and current/planned NuGet versioning/range selection
semantics and syntax.

The problem of encoding feature/bug-fix lists in a simple five part

version string is intractable. You haven't even begun to express the
complexities surrounding semantic versioning, until you start thinking
about thousands of products, spread across thousands of branches,
combining into pull-request builds, special test-only versions, A/B
flight tests and weekly releases of all of the above (daily releases
for many), multiplied by ~10K developer's snow-flakes.

The SemVer spec, defines a small, tractable piece of the overall

dev/sys-ops problems related to tracking the many-to-many
relationships between tens of thousands of components. The
inter/intra-dependency graph problem is well beyond the scope of the
SemVer specification. I argue that a well formed SemVer should be the
key to the root of that graph. Where and how that graph is implemented
is a problem that has yet to be adequately solved.

I vote this issue be closed. 

—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [2], or mute the
thread [3].
*
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/semver/semver","title":"semver/semver","subtitle":"GitHub
repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open
in
GitHub","url":"https://github.com/semver/semver"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jwdonahue
in #376: @coproc, I feel your pain. While the spec is a little weak in
the area of version selectors, it does define a complete sort order
that has been used many times to write actual code. I can attest to
the fact that there are ~10K users in the world, using tooling that I
helped create, which employs SemVer and adds range selection
capability, including the u003c operation (defined using set notation)
and has among its critical requirements, that it adhere to version
precedents defined in SemVer v2.0.0. We also had to thread the needle
between that spec and current/planned NuGet versioning/range selection
semantics and syntax.rnrnThe problem of encoding feature/bug-fix lists
in a simple five part version string is intractable. You haven't even
begun to express the complexities surrounding semantic versioning,
until you start thinking about thousands of products, spread across
thousands of branches, combining into pull-request builds, special
test-only versions, A/B flight tests and weekly releases of all of the
above (daily releases for many), multiplied by ~10K developer's
snow-flakes.rnrnThe SemVer spec, defines a small, tractable piece of
the overall dev/sys-ops problems related to tracking the many-to-many
relationships between tens of thousands of components. The
inter/intra-dependency graph problem is well beyond the scope of the
SemVer specification. I argue that a well formed SemVer should be the
key to the root of that graph. Where and how that graph is implemented
is a problem that has yet to be adequately solved.rnrnI vote this
issue be closed."}],"action":{"name":"View
Issue","url":"https://github.com/semver/semver/issues/376#issuecomment-347478898"}}}

Links:

[1] https://github.com/coproc
[2]
https://github.com/semver/semver/issues/376#issuecomment-347478898
[3]
https://github.com/notifications/unsubscribe-auth/AJ_km3kBZpJqP1DPWrey2ll2ZaskZASlks5s6992gaJpZM4Nt-3K

@coproc commented on GitHub (Nov 28, 2017): ok, I see your point. Although the defined sort order does not carry much information in the (very) general case, it is useful in most cases. Please close the issue. Wolfgang On Tue 28/11/17 11:24 , Joseph Donahue notifications@github.com sent: @coproc [1], I feel your pain. While the spec is a little weak in the area of version selectors, it does define a complete sort order that has been used many times to write actual code. I can attest to the fact that there are ~10K users in the world, using tooling that I helped create, which employs SemVer and adds range selection capability, including the < operation (defined using set notation) and has among its critical requirements, that it adhere to version precedents defined in SemVer v2.0.0. We also had to thread the needle between that spec and current/planned NuGet versioning/range selection semantics and syntax. The problem of encoding feature/bug-fix lists in a simple five part version string is intractable. You haven't even begun to express the complexities surrounding semantic versioning, until you start thinking about thousands of products, spread across thousands of branches, combining into pull-request builds, special test-only versions, A/B flight tests and weekly releases of all of the above (daily releases for many), multiplied by ~10K developer's snow-flakes. The SemVer spec, defines a small, tractable piece of the overall dev/sys-ops problems related to tracking the many-to-many relationships between tens of thousands of components. The inter/intra-dependency graph problem is well beyond the scope of the SemVer specification. I argue that a well formed SemVer should be the key to the root of that graph. Where and how that graph is implemented is a problem that has yet to be adequately solved. I vote this issue be closed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or mute the thread [3]. * {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/semver/semver","title":"semver/semver","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/semver/semver"}},"updates":{"snippets":[{"icon":"PERSON","message":"@jwdonahue in #376: @coproc, I feel your pain. While the spec is a little weak in the area of version selectors, it does define a complete sort order that has been used many times to write actual code. I can attest to the fact that there are ~10K users in the world, using tooling that I helped create, which employs SemVer and adds range selection capability, including the u003c operation (defined using set notation) and has among its critical requirements, that it adhere to version precedents defined in SemVer v2.0.0. We also had to thread the needle between that spec and current/planned NuGet versioning/range selection semantics and syntax.rnrnThe problem of encoding feature/bug-fix lists in a simple five part version string is intractable. You haven't even begun to express the complexities surrounding semantic versioning, until you start thinking about thousands of products, spread across thousands of branches, combining into pull-request builds, special test-only versions, A/B flight tests and weekly releases of all of the above (daily releases for many), multiplied by ~10K developer's snow-flakes.rnrnThe SemVer spec, defines a small, tractable piece of the overall dev/sys-ops problems related to tracking the many-to-many relationships between tens of thousands of components. The inter/intra-dependency graph problem is well beyond the scope of the SemVer specification. I argue that a well formed SemVer should be the key to the root of that graph. Where and how that graph is implemented is a problem that has yet to be adequately solved.rnrnI vote this issue be closed."}],"action":{"name":"View Issue","url":"https://github.com/semver/semver/issues/376#issuecomment-347478898"}}} Links: ------ [1] https://github.com/coproc [2] https://github.com/semver/semver/issues/376#issuecomment-347478898 [3] https://github.com/notifications/unsubscribe-auth/AJ_km3kBZpJqP1DPWrey2ll2ZaskZASlks5s6992gaJpZM4Nt-3K
GiteaMirror commented 2026-02-17 11:45:20 -06:00
Author
Owner
Copy Link

@jwdonahue commented on GitHub (Nov 28, 2017):

@coproc, the problem you and many others are trying to solve is something that needs to be layered on top of SemVer and other standards, but standards won't be enough, we have to build tooling on top of those.

Thanks for the close vote!

@jwdonahue commented on GitHub (Nov 28, 2017): @coproc, the problem you and many others are trying to solve is something that needs to be layered on top of SemVer and other standards, but standards won't be enough, we have to build tooling on top of those. Thanks for the close vote!
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 Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#281
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?