mirror of
https://github.com/semver/semver.git
synced 2026-07-11 06:53:03 -05:00
[GH-ISSUE #407] http://semver.org/ differ from semver.md, but both are 2.0.0 #1168
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1168
Reference in New Issue
Block a user
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?
Originally created by @nowox on GitHub (Nov 15, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/407
I see lots of differences between the http://semver.org/ website and the markdown file on this repository.
Unfortunately both information are marked with version 2.0.0. Obviously there are not the same
This is confusing, isn't ?
@FichteFoll commented on GitHub (Nov 15, 2017):
The semver.org version is the canonical 2.0.0, as far as I'm concerned. This repo is the development version, which may have not received a version bump in "code" since the last releace.
Maybe you could point out the exact differences?
@nowox commented on GitHub (Nov 16, 2017):
What I was looking for is the paragraph about Git version that speaks about the leading
vcharacter before version numbers. This information is completely absent from 2.0.0 (website) but visible on the 2.0.0 (master branch)Also I am very confused with this "development version". From your specifications, a version
2.0.0-rcor a version2.0.0-alphamust exactly have the same features implemented because they have the same major, minor and patch version. Also the version on the development branch, let's say on Git, will still be2.0.0unless a new tag is created. However, new features are implemented on the master branch, so at some point a2.0.0-10+g12abc3daversion will be incompatible with2.0.0-0+g1211aaac. How should I deal with that?@FichteFoll commented on GitHub (Nov 16, 2017):
The 2.0.0 release has been tagged on this repo as https://github.com/mojombo/semver/tree/v2.0.0. What you are talking about are pre-releases, which are also releases but not considered stable.
The version does not need to be increased with each commit because only releases need to have a version assigned to them. Anything between releases is whatever.
@jwdonahue commented on GitHub (Dec 6, 2017):
The working copy of the next release should be clearly marked as a prerelease version, "2.0.0-a.dev" or not have any version number in it at all. Perhaps we need some release automation to convert a place holder to whatever the next release should be? As-is, I agree with @nowox, that it is confusing.
@variadico commented on GitHub (Jan 6, 2018):
Seems like
masterand thev2.0.0tag have started differing since 2013. https://github.com/semver/semver/compare/v2.0.0...masterWhile I agree that not every commit should increase the version, perhaps there are some commits since 2013 that should be on the website. Specifically, I'd like to see Is "v1.2.3" a semantic version? on the website.
What's the release cycle like? Would it be too disruptive to have minor and patch releases? Not for every commit, but maybe once a year or something?
@jwdonahue commented on GitHub (Jan 29, 2018):
@phyowaimg, why did you link this thread to this thread? Seems kind of pointless. Did you have another thread in mind?
@aspiers commented on GitHub (May 16, 2018):
This repository should lead by example. The whole point of SemVer is that releases can be made frequently whilst clearly communicating the relative impact of the changes in each release. So it really doesn't look good if SemVer itself is leaving years in between each release, when there are useful changes which go unreleased for a long time.
So I vote for a new release. That would minimise the confusion stated in this issue.
@grv87 commented on GitHub (Dec 1, 2018):
Hit this considering making PR for breaking changes (semver 3.0.0).
I agree with @aspiers that releases should be more often.
Also I see that the project would benefit from README or contribute guidelines that would describe how often and when releases are made.
@grv87 commented on GitHub (Dec 1, 2018):
See also #454
@grv87 commented on GitHub (Dec 2, 2018):
There is a problem regarding applying semver to itself.
Current English version is
2.0.0. There are also a lot of translations of the same version (https://semver.org/lang/fr/spec/v2.0.0.html and so on).When exactly to bump patch field of SemVer version?
If we release
2.0.1, what should happen with these translations?Version
2.0.1doesn't say anything whether it was a fix in specification itself (and should be translated to other languages) or it was a typo/spelling error in English only that doesn't affect translations.@PallHaraldsson commented on GitHub (Jan 19, 2019):
Both the home page and the 2.0.0 page have "Build metadata SHOULD" while master has "Build metadata MUST".
a27ac08e16 (diff-55782f4857216898d46c6eca25fc5f32)@yoosefi commented on GitHub (Jul 2, 2019):
very meta
@alexandrtovmach commented on GitHub (Jun 10, 2020):
I'm going to investigate in sync script for this repos soon
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Thanks for report 👍 Closed in favor #573
@alexandrtovmach commented on GitHub (Jun 13, 2020):
FYI, now we have GitHub Action that will automatically sync main repo with website repo on daily basis: https://github.com/semver/semver.org/pull/265