Merge pull request #905 from elijaholmos/citation

Fix FAQ entry about fixing accidental breaking changes

.github/workflows/checks.yml

@@ -1,4 +1,4 @@
-name: Check chagnes
+name: Check changes
 
 on: [pull_request]
 
@@ -6,9 +6,10 @@ jobs:
   checks:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
-      - uses: actions/setup-node@v1
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
         with:
-          node-version: "12.x"
+          node-version: 16
+          cache: 'npm'
       - run: npm ci
-      - run: npm run lint
+      - run: npm run lint

CITATION.cff

@@ -0,0 +1,13 @@
+cff-version: 1.2.0
+message: "If you reference the Semantic Versioning Specification in your work, please use this metadata."
+abstract: '"Semantic Versioning" or "SemVer" contain a set of rules and requirements that dictate how version numbers are assigned and incremented.'
+authors:
+  - family-names: Preston-Werner
+    given-names: Tom
+  - name: The SemVer Team
+title: Semantic Versioning Specification
+version: 2.0.0
+date-released: 2013-06-18
+url: "https://semver.org"
+repository-code: "https://github.com/semver/semver"
+license: "CC-BY-3.0"

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/

CONTRIBUTING.md

@@ -13,11 +13,16 @@ Some changes do not require an RFC:
 * Typo fixes
 * Small wording clarifications that do not impact the semantics of the specification.
 
+### Translations
+
+Translations also don't require an RFC.
+If you want to contribute to the translations, you can visit the [website repository](https://github.com/semver/semver.org) and submit a PR.
+
 ## 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
 
@@ -27,13 +32,14 @@ Team members are added and removed based on the consensus of the existing team m
 
 The maintainers are:
 
-* [anangaur](https://github.com/anangaur) ([NuGet](https://www.nuget.org/))
 * [dherman](https://github.com/dherman) ([Notion](https://www.notionjs.com/))
 * [indirect](https://github.com/indirect) ([Bundler](https://bundler.io/))
 * [isaacs](https://github.com/isaacs) ([npm](https://www.npmjs.com/))
+* [JohnTitor](https://github.com/JohnTitor) ([crates.io](https://crates.io/))
 * [segiddins](https://github.com/segiddins) ([CocoaPods](https://cocoapods.org/))
 * [steveklabnik](https://github.com/steveklabnik) ([Cargo](https://crates.io/))
 * [Seldaek](https://github.com/Seldaek) ([Composer](https://getcomposer.org/))
+* [zkat](https://github.com/zkat) ([NuGet](https://www.nuget.org/))
 
 ## Participation commitment
 

README.md

@@ -1,5 +1,9 @@
 # Semantic Versioning Specification
 
-"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.
+"Semantic Versioning" or "SemVer" contains a set of rules and requirements that dictate how version numbers are assigned and incremented. You can find the full document in [semver.md](./semver.md) or visit our official website [semver.org](https://semver.org) to find previous versions and localized specifications.
 
-More info here...
+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.
+
+## Contributing
+
+See the [contribution guide](./CONTRIBUTING.md).

package.json

@@ -25,7 +25,7 @@
   },
   "homepage": "https://github.com/semver/semver#readme",
   "devDependencies": {
-    "remark-cli": "^8.0.0",
+    "remark-cli": "^11.0.0",
     "remark-frontmatter": "^2.0.0",
     "remark-lint-mdash-style": "^1.1.1",
     "remark-preset-lint-node": "^1.16.0"

semver.md

@@ -6,10 +6,10 @@ Summary
 
 Given a version number MAJOR.MINOR.PATCH, increment the:
 
-1. MAJOR version when you make incompatible API changes,
-1. MINOR version when you add functionality in a backwards compatible
-   manner, and
-1. PATCH version when you make backwards compatible bug fixes.
+1. MAJOR version when you make incompatible API changes
+1. MINOR version when you add functionality in a backward compatible
+   manner
+1. PATCH version when you make backward compatible bug fixes
 
 Additional labels for pre-release and build metadata are available as extensions
 to the MAJOR.MINOR.PATCH format.
@@ -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.
@@ -40,11 +40,11 @@ consist of documentation or be enforced by the code itself. Regardless, it is
 important that this API be clear and precise. Once you identify your public
 API, you communicate changes to it with specific increments to your version
 number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not
-affecting the API increment the patch version, backwards compatible API
-additions/changes increment the minor version, and backwards incompatible API
+affecting the API increment the patch version, backward compatible API
+additions/changes increment the minor version, and backward 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.
 
@@ -74,20 +74,20 @@ at any time. The public API SHOULD NOT be considered stable.
 is incremented after this release is dependent on this public API and how it
 changes.
 
-1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
+1. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward
 compatible bug fixes are introduced. A bug fix is defined as an internal
 change that fixes incorrect behavior.
 
-1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
+1. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward
 compatible functionality is introduced to the public API. It MUST be
 incremented if any public API functionality is marked as deprecated. It MAY be
 incremented if substantial new functionality or improvements are introduced
 within the private code. It MAY include patch level changes. Patch version
 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
+1. Major version X (X.y.z | X > 0) MUST be incremented if any backward
 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
@@ -99,7 +99,7 @@ precedence than the associated normal version. A pre-release version
 indicates that the version is unstable and might not satisfy the
 intended compatibility requirements as denoted by its associated
 normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7,
-1.0.0-x.7.z.92, 1.0.0-x-y-z.--.
+1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-.
 
 1. Build metadata MAY be denoted by appending a plus sign and a series of dot
 separated identifiers immediately following the patch or pre-release version.
@@ -107,25 +107,42 @@ Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-].
 Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining
 version precedence. Thus two versions that differ only in the build metadata,
 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.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
 --------------------------------------------------
@@ -238,7 +255,7 @@ and then increment the minor version for each subsequent release.
 
 If your software is being used in production, it should probably already be
 1.0.0. If you have a stable API on which users have come to depend, you should
-be 1.0.0. If you're worrying a lot about backwards compatibility, you should
+be 1.0.0. If you're worrying a lot about backward compatibility, you should
 probably already be 1.0.0.
 
 ### Doesn't this discourage rapid development and fast iteration?
@@ -247,7 +264,7 @@ Major version zero is all about rapid development. If you're changing the API
 every day you should either still be in version 0.y.z or on a separate
 development branch working on the next major version.
 
-### If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?
+### If even the tiniest backward incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?
 
 This is a question of responsible development and foresight. Incompatible
 changes should not be introduced lightly to software that has a lot of
@@ -265,11 +282,11 @@ nobody knows how to use your software, or what methods are safe to call. In
 the long run, Semantic Versioning, and the insistence on a well defined public
 API can keep everyone and everything running smoothly.
 
-### What do I do if I accidentally release a backwards incompatible change as a minor version?
+### What do I do if I accidentally release a backward incompatible change as a minor version?
 
 As soon as you realize that you've broken the Semantic Versioning spec, fix
-the problem and release a new minor version that corrects the problem and
-restores backwards compatibility. Even under this circumstance, it is
+the problem and release a new patch version that corrects the problem and
+restores backward compatibility. Even under this circumstance, it is
 unacceptable to modify versioned releases. If it's appropriate,
 document the offending version and inform your users of the problem so that
 they are aware of the offending version.
@@ -281,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)?
@@ -305,7 +322,7 @@ that users can smoothly transition to the new API.
 
 ### Does SemVer have a size limit on the version string?
 
-No, but use good judgment. A 255 character version string is probably overkill,
+No, but use good judgment. A 255 character version string is probably an overkill,
 for example. Also, specific systems may impose their own limits on the size of
 the string.