[PR #107] [MERGED] Section 9: Clarify pre-release definition #2640

New Issue

GiteaMirror · 2026-04-23T03:06:10-05:00

GiteaMirror commented

2026-04-23 03:06:10 -05:00

📋 Pull Request Information

Original PR: https://github.com/semver/semver/pull/107
Author: @haacked
Created: 6/10/2013
Status: ✅ Merged
Merged: 6/10/2013
Merged by: @haacked

Base: master ← Head: clarify-prerelease

📝 Commits (1)

dee96a6 Section 9: Clarify pre-release definition

📊 Changes

1 file changed (+9 additions, -8 deletions)

View changed files

📝 semver.md (+9 -8)

📄 Description

This is cherry picked from #103 and related to #86

Remove confusing 'satisfies' usage.
Specify that pre-release identifiers cannot be empty.

I'm actually not happy about removing the 'satisfies' usage.

If I understand @isaacs concern correctly, stating that 1.0.0-beta satisfies 1.0.0 implies a specific version range implementation and he is against that because other systems have different ways of specifying version ranges.

For NuGet, we've taken to using the Maven range specification. [1.0, 2.0) indicates a version that's 1.0 or greater, but strictly less than 2.0

According to SemVer as it is today, 1.0.0-beta fits within that range. That's the intent of 'satisfies' even though it is less than 1.0.0. The way I often think about it is when you allow pre-release versions in your dependency resolution, 1.0.0 can be considered 1.0.0- Ω where Ω has a larger precedence than any valid pre-release version.

I think we can get to a definition that expresses our intent without implying a specific implementation.

Something to the effect of:

When pre-release versions are allowed to be included in version comparisons (such as in dependency
resolution algorithms), a pre-release version SHOULD be included in any set that it's associated
normal version is, but have lower precedence than its associated normal version.

^^^ The language there could be improved, but I think it hints at what I'm getting at. Pre-release is adding another dimension. Kind of like adding something to the y-axis while we've been looking at the x-axis all along.

How pre-release versions are "allowed" to be included is an implementation detail of the respective systems. For some, it might be indicated by the version range syntax. For others it's by passing a -pre flag into the system.

What do you think?

/cc @isaacs, @tieske, @TimLovellSmith, @tbull, @jeffhandley

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/semver/semver/pull/107 **Author:** [@haacked](https://github.com/haacked) **Created:** 6/10/2013 **Status:** ✅ Merged **Merged:** 6/10/2013 **Merged by:** [@haacked](https://github.com/haacked) **Base:** `master` ← **Head:** `clarify-prerelease` --- ### 📝 Commits (1) - [`dee96a6`](https://github.com/semver/semver/commit/dee96a6b522e31346fa5030139ec9081f183670a) Section 9: Clarify pre-release definition ### 📊 Changes **1 file changed** (+9 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `semver.md` (+9 -8) </details> ### 📄 Description This is cherry picked from #103 and related to #86 - Remove confusing 'satisfies' usage. - Specify that pre-release identifiers cannot be empty. I'm actually not happy about removing the 'satisfies' usage. If I understand @isaacs concern correctly, stating that `1.0.0-beta` satisfies `1.0.0` implies a specific version range implementation and he is against that because other systems have different ways of specifying version ranges. For NuGet, we've taken to using the Maven range specification. `[1.0, 2.0)` indicates a version that's `1.0 or greater, but strictly less than 2.0` According to SemVer as it is today, `1.0.0-beta` fits within that range. That's the intent of 'satisfies' even though it is less than `1.0.0`. The way I often think about it is when you allow pre-release versions in your dependency resolution, `1.0.0` can be considered `1.0.0- Ω` where `Ω` has a larger precedence than any valid pre-release version. I think we can get to a definition that expresses our intent without implying a specific implementation. Something to the effect of: ``` When pre-release versions are allowed to be included in version comparisons (such as in dependency resolution algorithms), a pre-release version SHOULD be included in any set that it's associated normal version is, but have lower precedence than its associated normal version. ``` ^^^ The language there could be improved, but I think it hints at what I'm getting at. Pre-release is adding another dimension. Kind of like adding something to the y-axis while we've been looking at the x-axis all along. How pre-release versions are "allowed" to be included is an implementation detail of the respective systems. For some, it might be indicated by the version range syntax. For others it's by passing a `-pre` flag into the system. What do you think? /cc @isaacs, @tieske, @TimLovellSmith, @tbull, @jeffhandley --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-04-23 03:06:10 -05:00

GiteaMirror closed this issue

2026-04-23 03:06:11 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2640