[PR #202] [CLOSED] Fix for issue #200: "Nightly builds not supported" #5021

New Issue

2026-06-13T13:24:12-05:00

GiteaMirror commented

2026-06-13 13:24:12 -05:00

📋 Pull Request Information

Original PR: https://github.com/semver/semver/pull/202
Author: @mearns
Created: 5/28/2014
Status: ❌ Closed

Base: master ← Head: master

📝 Commits (1)

cfb8d75 Fix for issue #200: "Nightly builds not supported"

📊 Changes

1 file changed (+41 additions, -13 deletions)

View changed files

📝 semver.md (+41 -13)

📄 Description

Implemented a suggestion that arose from discussion about lack of
support for development builds in which the version number for the next
official release is unknown. The suggestion is to replace the statement
that metadata MUST NOT be considered in precedence with a statement that
metadata SHOULD be considered in precedence, and that it has a higher
precedence than the corresponding normal or pre-release version.
Pull request also include additional details, examples, and one
additional FAQ regarding development builds.

The main justification for this change is that an increasingly common
develpoment model is fast paced and flexible, often with a fixed length
release cycle, or an as-needed release plan. In such scenarios, it is
commonly the case that one does not know what changes will be included
in the next release, and therefore does not know what semver should be
used for the next release until the release is ready (since changes to
the public interface are not known). The pre-release version identifiers
are therefore ineffective for between-releases versioning (i.e.,
development/nightly releases) because they have lower priority.
Therefore, a similar "post-release" identifier is required to support
this type of development.

The build metadata field was identified as an appropriate field to use
for this information, if it were to be considered with regards to
precedence. The following reasons for using the metadata field were
identified:

    1. Build metadata without impact on the precedence is
    unhelpful at best, and harmful at worst. If you two releases are
    not different in any way, they should have the same version
    number (i.e., they should be the same release). If they are
    different in anyway, they should be different versions and one
    should take precedence over the other.

    2. The pre-release identifier sequence are has lower precedence
    and is preceded by a "minus", the metadata identifier sequence
    is preceded by a "plus" and is therefore a fitting location for
    "post-release" identifiers with higher precedence.

The semver spec version number was tentatively bumped from 2.0.0 to
2.1.0. This is of course only a suggestion, but it seems like it could
fit as a minor change (i.e., an addition to the public interface). For
instance, existing semver implementations can continue to function
according to the 2.0.0 version without breaking, they just may not
support (for instance) upgrading to a post-release development version
because it will identify it as having the same precedence. An
implementation which wants to suppor the 2.1.0 addition could default to
the 2.0.0 behavior, and require an additional configuration / option to
allow such an upgrade to a development version. This is also fitting
because most users will not want to upgrade to development versions,
they will prefer to stick to official releases.

For more details, please see issue #200 on the original mojombo/semver
repository, in which a length discussion occurred.

_{🔄 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/202 **Author:** [@mearns](https://github.com/mearns) **Created:** 5/28/2014 **Status:** ❌ Closed **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`cfb8d75`](https://github.com/semver/semver/commit/cfb8d75c7a3b8229b8f834908ea9e3565726db36) Fix for issue #200: "Nightly builds not supported" ### 📊 Changes **1 file changed** (+41 additions, -13 deletions) <details> <summary>View changed files</summary> 📝 `semver.md` (+41 -13) </details> ### 📄 Description Implemented a suggestion that arose from discussion about lack of support for development builds in which the version number for the next official release is unknown. The suggestion is to replace the statement that metadata MUST NOT be considered in precedence with a statement that metadata SHOULD be considered in precedence, and that it has a higher precedence than the corresponding normal or pre-release version. Pull request also include additional details, examples, and one additional FAQ regarding development builds. The main justification for this change is that an increasingly common develpoment model is fast paced and flexible, often with a fixed length release cycle, or an as-needed release plan. In such scenarios, it is commonly the case that one does not know what changes will be included in the next release, and therefore does not know what semver should be used for the next release until the release is ready (since changes to the public interface are not known). The pre-release version identifiers are therefore ineffective for between-releases versioning (i.e., development/nightly releases) because they have lower priority. Therefore, a similar "post-release" identifier is required to support this type of development. The build metadata field was identified as an appropriate field to use for this information, if it were to be considered with regards to precedence. The following reasons for using the metadata field were identified: ``` 1. Build metadata without impact on the precedence is unhelpful at best, and harmful at worst. If you two releases are not different in any way, they should have the same version number (i.e., they should be the same release). If they are different in anyway, they should be different versions and one should take precedence over the other. 2. The pre-release identifier sequence are has lower precedence and is preceded by a "minus", the metadata identifier sequence is preceded by a "plus" and is therefore a fitting location for "post-release" identifiers with higher precedence. ``` The semver spec version number was tentatively bumped from 2.0.0 to 2.1.0. This is of course only a suggestion, but it seems like it could fit as a minor change (i.e., an addition to the public interface). For instance, existing semver implementations can continue to function according to the 2.0.0 version without breaking, they just may not support (for instance) upgrading to a post-release development version because it will identify it as having the same precedence. An implementation which wants to suppor the 2.1.0 addition could default to the 2.0.0 behavior, and require an additional configuration / option to allow such an upgrade to a development version. This is also fitting because most users will not want to upgrade to development versions, they will prefer to stick to official releases. For more details, please see issue #200 on the original mojombo/semver repository, in which a length discussion occurred. --- <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-06-13 13:24:12 -05:00

GiteaMirror closed this issue

2026-06-13 13:24:16 -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#5021