Explicit the use of Semantic Versioning

jazzband · Feb 6, 2019 · 214ccf7 · 214ccf7
1 parent 2d9ca9d
commit 214ccf7
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -7,4 +7,4 @@
 - [ ] Provided the tests for the changes.
 - [ ] Requested a review from another contributor.
 - [ ] Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
-- [ ] Assign the PR to an existing or new milestone for the target version (respecting Semantic Versioning).
+- [ ] Assign the PR to an existing or new milestone for the target version (following [Semantic Versioning](https://blog.versioneye.com/2014/01/16/semantic-versioning/)).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -29,7 +29,7 @@ To help keeping track of the releases and their changes, here's the current rele
   Check the previous release changelog format for an example. Don't forget the "Thanks @contributor" mentions.
 - Make sure that the tests/CI still pass.
 - Once ready, go to `Github pip-tools Homepage > releases tab > Draft a new release` and type in:
-  - *Tag version:* The exact version number. *Ex: 3.4.0*
+  - *Tag version:* The exact version number, following [Semantic Versioning](https://blog.versioneye.com/2014/01/16/semantic-versioning/). *Ex: 3.4.0*
   - *Target:* master. As a general rule, the HEAD commit of the master branch should be the release target.
   - *Release title:* Same as the tag. *Ex: 3.4.0*
   - *Describe this release:* Copy of this release's changelog segment.