[GH-ISSUE #86] Clarify what 'satisfy' means #1796

New Issue

GiteaMirror · 2026-04-20T09:24:01-05:00

GiteaMirror commented

2026-04-20 09:24:01 -05:00

Originally created by @TimLovellSmith on GitHub (Apr 17, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/86

"Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92."

What does it mean that 1.0.0-alpha satisfies 1.0.0? This is the first time the terminology is used.

Originally created by @TimLovellSmith on GitHub (Apr 17, 2013). Original GitHub issue: https://github.com/semver/semver/issues/86 "Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92." What does it mean that 1.0.0-alpha satisfies 1.0.0? This is the first time the terminology is used.

GiteaMirror closed this issue

2026-04-20 09:24:01 -05:00

GiteaMirror commented

2026-04-20 09:24:02 -05:00

@tbull commented on GitHub (Apr 18, 2013):

I think, the 'satisfy' wording is clearer than the 'compatible' wording. It might be just me, but 'satisfy' seems to already imply the precedence, which is then explicitly stated by "but have a lower precedence". This results in some redundancy, which is a good thing in human communication (as opposed to data storage).

BTW, shouldn't it be "but have lower precedence" (without the "a")?

@tbull commented on GitHub (Apr 18, 2013): I think, the 'satisfy' wording is clearer than the 'compatible' wording. It might be just me, but 'satisfy' seems to already imply the precedence, which is then explicitly stated by "but have a lower precedence". This results in some redundancy, which is a good thing in human communication (as opposed to data storage). BTW, shouldn't it be "but have lower precedence" (without the "a")?

GiteaMirror commented

2026-04-20 09:24:03 -05:00

@jeffhandley commented on GitHub (Apr 30, 2013):

This seems like a good clarification to make. The way I comprehend the spec, version 2.0.0-beta could satisfy a request for version 2.0.0.

Perhaps we could change the wording to "Pre-release versions satisfy requests for but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92."

@jeffhandley commented on GitHub (Apr 30, 2013): This seems like a good clarification to make. The way I comprehend the spec, version 2.0.0-beta could satisfy a request for version 2.0.0. Perhaps we could change the wording to "Pre-release versions satisfy **_requests for_** but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92."

GiteaMirror commented

2026-04-20 09:24:04 -05:00

@TimLovellSmith commented on GitHub (May 3, 2013):

OK so this is basically saying that when you are writing a system that at build-time or run-time tries to satisfy dependencies, you should consider prerelease versions and non-prerelease versions substitutable in a limited number of scenarios:
-substitute prerelease for release? you should support this, but only if the release version does not exist
-substitute release for prerelease? not supported

The funny thing about this is that the 'satisfy' notion does not make sense without talking about dependencies, and semver.org does not claim to talk about dependencies, it just claims to talk about what are the rules for assigning versions.

Is it possible to rewrite this satisfy rule in a way such that it becomes a rule about assigning versions? Or does this really belong in a separate section at the bottom about 'how to satisfy dependencies automatically'

@TimLovellSmith commented on GitHub (May 3, 2013): OK so this is basically saying that when you are writing a system that at build-time or run-time tries to satisfy dependencies, you should consider prerelease versions and non-prerelease versions substitutable in a limited number of scenarios: -substitute prerelease for release? you should support this, but only if the release version does not exist -substitute release for prerelease? not supported The funny thing about this is that the 'satisfy' notion does not make sense without talking about dependencies, and semver.org does not claim to talk about dependencies, it just claims to talk about what are the rules for assigning versions. Is it possible to rewrite this satisfy rule in a way such that it becomes a rule about assigning versions? Or does this really belong in a separate section at the bottom about 'how to satisfy dependencies automatically'

GiteaMirror commented

2026-04-20 09:24:04 -05:00

@TimLovellSmith commented on GitHub (May 3, 2013):

I also wonder: does the current semver.org statement about prerelease versions actually help you with dependency hell?
Nowhere does it state whether prerelease versions (-prerelease) and non-prerelease versions with same version number are required to be backwards compatible with each other.
Which is what you really care about if you are trying to avoid a dependency hell involving prerelease versions.
I also suspect that in practice prerelease versions tend
a) not to be compatible with the previous minor version number (if it's a prerelease of the minor version increment)
b) not to be compatible with the final release version with same as own version number
since
a) prerelease versions can contain bugs
b) release versions of prereleased versions can contain bug fixes or api changes which are breaking changes

But if this is the case, saying that prerelease versions and release versions substitutable doesn't seem like the right thing to do, logically it leads to breakage.

@TimLovellSmith commented on GitHub (May 3, 2013): I also wonder: does the current semver.org statement about prerelease versions actually help you with dependency hell? Nowhere does it state whether prerelease versions (-prerelease) and non-prerelease versions with same version number are required to be backwards compatible with each other. Which is what you really care about if you are trying to avoid a dependency hell involving prerelease versions. I also suspect that in practice prerelease versions tend a) not to be compatible with the previous minor version number (if it's a prerelease of the minor version increment) b) not to be compatible with the final release version with same as own version number since a) prerelease versions can contain bugs b) release versions of prereleased versions can contain bug fixes or api changes which are breaking changes But if this is the case, saying that prerelease versions and release versions substitutable doesn't seem like the right thing to do, logically it leads to breakage.

GiteaMirror commented

2026-04-20 09:24:05 -05:00

@TimLovellSmith commented on GitHub (May 3, 2013):

(By the way @tbull I think satisfy and precendence are completely different things. Precedence is a logical ordering from low to high. 2.0 may or may not satisfy 1.0, and vice versa in terms of compatibility, but definitely one precedes the other...)

@TimLovellSmith commented on GitHub (May 3, 2013): (By the way @tbull I think satisfy and precendence are completely different things. Precedence is a logical ordering from low to high. 2.0 may or may not satisfy 1.0, and vice versa in terms of compatibility, but definitely one precedes the other...)

GiteaMirror commented

2026-04-20 09:24:06 -05:00

@Tieske commented on GitHub (May 3, 2013):

@TimLovellSmith 👍 see also #30

@Tieske commented on GitHub (May 3, 2013): @TimLovellSmith :+1: see also #30

GiteaMirror commented

2026-04-20 09:24:06 -05:00

@haacked commented on GitHub (May 6, 2013):

The funny thing about this is that the 'satisfy' notion does not make sense without talking about dependencies, and semver.org does not claim to talk about dependencies...

It's right there in the first paragraph of the spec.

In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

Regarding pre-releases, this is why package managers tend to ignore pre-release versions unless you opt-in. Pre-releases imply intent of compatibility, not actual compatibility. Then again, you could say the same for release versions given how buggy software can be in general. 😛 Pre-release just means you're less confident that your intent meets reality than a released version.

Imma close this as there's no actionable item not covered elsewhere as far as I can tell.

@haacked commented on GitHub (May 6, 2013): > The funny thing about this is that the 'satisfy' notion does not make sense without talking about dependencies, and semver.org does not claim to talk about dependencies... It's right there in the first paragraph of the spec. > In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair. Regarding pre-releases, this is why package managers tend to ignore pre-release versions unless you opt-in. Pre-releases imply intent of compatibility, not actual compatibility. Then again, you could say the same for release versions given how buggy software can be in general. :stuck_out_tongue: Pre-release just means you're less confident that your intent meets reality than a released version. Imma close this as there's no actionable item not covered elsewhere as far as I can tell.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1796