From e3ea339279549e015463b40a08f672e3d180e3f4 Mon Sep 17 00:00:00 2001 From: DannyS712 <46829944+DannyS712@users.noreply.github.com> Date: Sun, 5 Apr 2020 01:24:45 -0700 Subject: [PATCH 01/10] Minor copyedit to CONTRIBUTING.md Add a missing "to", define the term "PR" (required making the sentence use the singular for parallelism with "RFC") --- CONTRIBUTING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ce27859..6be94ea 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,7 +4,7 @@ The "RFC" (request for comments) process is intended to provide a consistent and ## When you need to follow this process -You need to follow this process if you intend to make "substantial" changes to the specification or the RFC process itself. What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the specification you are proposing to change, but may include the following: +You need to follow this process if you intend to make "substantial" changes to the specification or to the RFC process itself. What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the specification you are proposing to change, but may include the following: * Changes to the meaning of the specification. @@ -15,9 +15,9 @@ Some changes do not require an RFC: ## What the process is -When pull requests are opened against the specification or this repository, they may be -tagged with an "RFC" tag ("RFC" from here forward). RFCs require the consensus of -all team members (see below) to merge. +When a pull request ("PR" from here forward) is opened against the specification or +this repository, it may be tagged with an "RFC" tag ("RFC" from here forward). +RFCs require the consensus of all team members (see below) to merge. ## The SemVer Team From 8aeb2c76219611dbefb284c8df14b61ea8a34059 Mon Sep 17 00:00:00 2001 From: DannyS712 <46829944+DannyS712@users.noreply.github.com> Date: Sun, 5 Apr 2020 01:25:43 -0700 Subject: [PATCH 02/10] Add a missing period to CODE_OF_CONDUCT.md The final sentence was missing a period --- CODE_OF_CONDUCT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 2c66e02..0403482 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -40,7 +40,7 @@ Project maintainers who do not follow or enforce the Code of Conduct in good fai ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]. [homepage]: http://contributor-covenant.org [version]: http://contributor-covenant.org/version/1/4/ From 5a2850504c2efff4c964e249f447545cd0680b8d Mon Sep 17 00:00:00 2001 From: DannyS712 <46829944+DannyS712@users.noreply.github.com> Date: Tue, 28 Apr 2020 22:02:13 -0700 Subject: [PATCH 03/10] Tweak Per review comment --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6be94ea..2957622 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,7 +4,7 @@ The "RFC" (request for comments) process is intended to provide a consistent and ## When you need to follow this process -You need to follow this process if you intend to make "substantial" changes to the specification or to the RFC process itself. What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the specification you are proposing to change, but may include the following: +You need to follow this process if you intend to make "substantial" changes to the specification or the RFC process itself. What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the specification you are proposing to change, but may include the following: * Changes to the meaning of the specification. From 5fddddab80e02c6195cc30a9f98d9e57dbe10f1a Mon Sep 17 00:00:00 2001 From: Thomas Schraitle Date: Fri, 8 May 2020 21:01:56 +0200 Subject: [PATCH 04/10] Fix #561: improve readability of item 11 Introduce a list to separate the different rules to make item 11 more accessible. --- semver.md | 49 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 16 deletions(-) diff --git a/semver.md b/semver.md index ac37a19..f6a71f8 100644 --- a/semver.md +++ b/semver.md @@ -111,22 +111,39 @@ have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD. 1. Precedence refers to how versions are compared to each other when ordered. -Precedence MUST be calculated by separating the version into major, minor, patch -and pre-release identifiers in that order (Build metadata does not figure -into precedence). Precedence is determined by the first difference when -comparing each of these identifiers from left to right as follows: Major, minor, -and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < -2.1.0 < 2.1.1. When major, minor, and patch are equal, a pre-release version has -lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence -for two pre-release versions with the same major, minor, and patch version MUST -be determined by comparing each dot separated identifier from left to right -until a difference is found as follows: identifiers consisting of only digits -are compared numerically and identifiers with letters or hyphens are compared -lexically in ASCII sort order. Numeric identifiers always have lower precedence -than non-numeric identifiers. A larger set of pre-release fields has a higher -precedence than a smaller set, if all of the preceding identifiers are equal. -Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < -1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + + 1. Precedence MUST be calculated by separating the version into major, + minor, patch and pre-release identifiers in that order (Build metadata + does not figure into precedence). + + 1. Precedence is determined by the first difference when comparing each of + these identifiers from left to right as follows: Major, minor, and patch + versions are always compared numerically. + + Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. + + 1. When major, minor, and patch are equal, a pre-release version has lower + precedence than a normal version: + + Example: 1.0.0-alpha < 1.0.0. + + 1. Precedence for two pre-release versions with the same major, minor, and + patch version MUST be determined by comparing each dot separated identifier + from left to right until a difference is found as follows: + + 1. Identifiers consisting of only digits are compared numerically. + + 1. Identifiers with letters or hyphens are compared lexically in ASCII + sort order. + + 1. Numeric identifiers always have lower precedence than non-numeric + identifiers. + + 1. A larger set of pre-release fields has a higher precedence than a + smaller set, if all of the preceding identifiers are equal. + + Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. Backus–Naur Form Grammar for Valid SemVer Versions -------------------------------------------------- From 371f7fac38acf2bcaedf3bb5565b6397355f00e6 Mon Sep 17 00:00:00 2001 From: Alexandr Tovmach Date: Sat, 20 Jun 2020 00:48:18 +0300 Subject: [PATCH 05/10] fix: Updated list indentation --- semver.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/semver.md b/semver.md index f6a71f8..7bfd68f 100644 --- a/semver.md +++ b/semver.md @@ -143,7 +143,7 @@ have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < - 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. + 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. Backus–Naur Form Grammar for Valid SemVer Versions -------------------------------------------------- From 0f0b28d52757e9b0fda8b24293a80f0e115138ce Mon Sep 17 00:00:00 2001 From: DannyS712 <46829944+DannyS712@users.noreply.github.com> Date: Mon, 22 Jun 2020 18:09:22 -0700 Subject: [PATCH 06/10] Code of conduct: Use https links contributor-covenant.org supports https, and as a result links shouldn't be using http --- CODE_OF_CONDUCT.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 0403482..ffeefca 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -40,7 +40,7 @@ Project maintainers who do not follow or enforce the Code of Conduct in good fai ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]. +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [https://contributor-covenant.org/version/1/4][version]. -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ +[homepage]: https://contributor-covenant.org +[version]: https://contributor-covenant.org/version/1/4/ From fb72e13228b26030a1e962c449e7376a90da3ed4 Mon Sep 17 00:00:00 2001 From: Minasie Shibeshi Date: Fri, 26 Jun 2020 08:35:15 +0300 Subject: [PATCH 07/10] Update checks.yml Typo on workflow name --- .github/workflows/checks.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/checks.yml b/.github/workflows/checks.yml index e1946cf..766ddd0 100644 --- a/.github/workflows/checks.yml +++ b/.github/workflows/checks.yml @@ -1,4 +1,4 @@ -name: Check chagnes +name: Check changes on: [pull_request] @@ -11,4 +11,4 @@ jobs: with: node-version: "12.x" - run: npm ci - - run: npm run lint \ No newline at end of file + - run: npm run lint From da15534d3511bcb23a03e23a3edeec18d0d06a51 Mon Sep 17 00:00:00 2001 From: Adam Ralph Date: Sat, 10 Oct 2020 20:02:46 +0200 Subject: [PATCH 08/10] switch to plural first person pronoun --- semver.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/semver.md b/semver.md index bdde525..cfbe982 100644 --- a/semver.md +++ b/semver.md @@ -31,7 +31,7 @@ specified too loosely, you will inevitably be bitten by version promiscuity Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward. -As a solution to this problem, I propose a simple set of rules and +As a solution to this problem, we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. @@ -44,7 +44,7 @@ affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. -I call this system "Semantic Versioning." Under this scheme, version numbers +We call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. @@ -298,7 +298,7 @@ Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix -a bug or introduce new functionality. I would usually expect additional code +a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it's obviously a minor level increment. ### What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)? From 8cf48fbb2547b1153f1799391e5d30219c7253fe Mon Sep 17 00:00:00 2001 From: Iulian Onofrei <6d0847b9@opayq.com> Date: Fri, 12 Feb 2021 19:35:56 +0200 Subject: [PATCH 09/10] Fix typo --- semver.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/semver.md b/semver.md index bdde525..3648921 100644 --- a/semver.md +++ b/semver.md @@ -87,7 +87,7 @@ MUST be reset to 0 when minor version is incremented. 1. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor -and patch level changes. Patch and minor version MUST be reset to 0 when major +and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented. 1. A pre-release version MAY be denoted by appending a hyphen and a From 18771b651ddbc695b2d9c90fb60a4d808af62380 Mon Sep 17 00:00:00 2001 From: Adam Ralph Date: Mon, 26 Jul 2021 10:45:22 +0200 Subject: [PATCH 10/10] explain how changes are published to the website --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index fa7b368..f6dcaf7 100644 --- a/README.md +++ b/README.md @@ -2,3 +2,4 @@ "Semantic Versioning" or "SemVer" contain a set of rules and requirements that dictate how version numbers are assigned and incremented. You can find full document in [semver.md](./semver.md) or visit our official website [semver.org](https://semver.org) to find previous versions and localized specifications. +Changes to the document are published to the website by a [GitHub Actions workflow](https://github.com/semver/semver.org/blob/gh-pages/.github/workflows/sync.yml) which runs once each day.