releases: use +dev as in-development suffix #1050
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Under SemVer, the suffix "-dev" actually indicates a pre-release, meaning the way we've been using the suffix indicates that "1.0.0-dev" is *older* than "1.0.0" when we've used the suffix to indicate the opposite. With most package managers, the "+dev" suffix correctly indicates that the version is newer (i.e. 1.0.1 > 1.0.0+dev > 1.0.0), though under SemVer "+dev" build tags must be ignored when doing version comparisons (meaning 1.0.0+dev == 1.0.0 under SemVer). However, from a SemVer perspective the unreleased version is inarguably closer to being equal to the last release than being older than it. As a specification we also allow extensibility of various parts, meaning that if someone uses an as-yet-unreleased version it seems reasonable to me for it to be treated as the same (from a SemVer perspective) as the last released version it's based on. The other option would be to continue to use "-dev" as a suffix but bump the rest of the version number to the next version we plan to release, but this could also cause issues (we could have a "pre-release" for a release that never happened). Using "+dev" seems more sensible. Switching to "+dev" also matches the way runc and umoci are versioned, and allows downstreams that use as-yet-unreleased versions of our specs to have their spec versions be treated as the same as the released version by other consumers. Signed-off-by: Aleksa Sarai <asarai@suse.de>
cyphar
requested review from
jonjohnsonjr,
jonboulle,
stevvooe,
sudo-bmitch,
sajayantony,
tianon and
vbatts
as code owners
Merged
sudo-bmitch
approved these changes
Apr 21, 2023
|
Another option would be to bump the patch version and add |
|
This has been merged on runtime-spec. I think we should also merge here to keep the specs aligned. @opencontainers/image-spec-maintainers PTAL |
sudo-bmitch
added a commit
to sudo-bmitch/image-spec
that referenced
this pull request
May 22, 2023
Signed-off-by: Brandon Mitchell <git@bmitch.net>
sajayantony
approved these changes
May 22, 2023
sudo-bmitch
added a commit
that referenced
this pull request
May 24, 2023
Apply version change from #1050
rchincha
pushed a commit
to rchincha/image-spec
that referenced
this pull request
May 29, 2024
Signed-off-by: Brandon Mitchell <git@bmitch.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Under SemVer, the suffix "-dev" actually indicates a pre-release, meaning the way we've been using the suffix indicates that "1.0.0-dev" is older than "1.0.0" when we've used the suffix to indicate the opposite.
With most package managers, the "+dev" suffix correctly indicates that the version is newer (i.e. 1.0.1 > 1.0.0+dev > 1.0.0), though under SemVer "+dev" build tags must be ignored when doing version comparisons (meaning 1.0.0+dev == 1.0.0 under SemVer). However, from a SemVer perspective the unreleased version is inarguably closer to being equal to the last release than being older than it. As a specification we also allow extensibility of various parts, meaning that if someone uses an as-yet-unreleased version it seems reasonable to me for it to be treated as the same (from a SemVer perspective) as the last released version it's based on.
The other option would be to continue to use "-dev" as a suffix but bump the rest of the version number to the next version we plan to release, but this could also cause issues (we could have a "pre-release" for a release that never happened). Using "+dev" seems more sensible.
Switching to "+dev" also matches the way runc and umoci are versioned, and allows downstreams that use as-yet-unreleased versions of our specs to have their spec versions be treated as the same as the released version by other consumers.
Signed-off-by: Aleksa Sarai asarai@suse.de