Skip to content

Commit 78b83a2

Browse files
committed
Address review comments from @webknjaz
1 parent 24fe903 commit 78b83a2

File tree

1 file changed

+17
-14
lines changed

1 file changed

+17
-14
lines changed

source/discussions/versioning.rst

Lines changed: 17 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -16,18 +16,18 @@ needs of that particular project, but in order to be compatible with tools like
1616
:ref:`pip`, all of them are required to comply with a flexible format for
1717
version identifiers, for which the authoritative reference is the
1818
:ref:`specification of version specifiers <version-specifiers>`. Here are some
19-
examples of version numbers:
20-
21-
- A simple version (final release): 1.2.0
22-
- A development release: 1.2.0.dev1
23-
- An alpha release: 1.2.0a1
24-
- A beta release: 1.2.0b1
25-
- A release candidate: 1.2.0rc1
26-
- A post-release: 1.2.0.post1
27-
- A post-release of an alpha release (possible, but discouraged): 1.2.0a1.post1
28-
- A simple version with only two components: 23.12
29-
- A simple version with just one component (possible, but discouraged): 42
30-
- A version with an epoch: 1!1.0
19+
examples of version numbers [#version-examples]_:
20+
21+
- A simple version (final release): ``1.2.0``
22+
- A development release: ``1.2.0.dev1``
23+
- An alpha release: ``1.2.0a1``
24+
- A beta release: ``1.2.0b1``
25+
- A release candidate: ``1.2.0rc1``
26+
- A post-release: ``1.2.0.post1``
27+
- A post-release of an alpha release (possible, but discouraged): ``1.2.0a1.post1``
28+
- A simple version with only two components: ``23.12``
29+
- A simple version with just one component: ``42``
30+
- A version with an epoch: ``1!1.0``
3131

3232
Projects can use a cycle of pre-releases to support testing by their users
3333
before a final release. In order, the steps are: alpha releases, beta releases,
@@ -68,11 +68,11 @@ Semantic versioning
6868
-------------------
6969

7070
The idea of *semantic versioning* (or SemVer) is to use 3-part version numbers,
71-
*major.minor.maintenance*, where the project author increments:
71+
*major.minor.patch*, where the project author increments:
7272

7373
- *major* when they make incompatible API changes,
7474
- *minor* when they add functionality in a backwards-compatible manner, and
75-
- *maintenance*, when they make backwards-compatible bug fixes.
75+
- *patch*, when they make backwards-compatible bug fixes.
7676

7777
A majority of Python projects use a scheme that resembles semantic
7878
versioning. However, most projects, especially larger ones, do not strictly
@@ -159,6 +159,8 @@ since the latest release, setuptools-scm generates a version like
159159

160160
--------------------------------------------------------------------------------
161161

162+
.. [#version-examples] Some more examples of unusual version numbers are
163+
given in a `blog post <versions-seth-larson>`_ by Seth Larson.
162164
163165
.. [#semver-strictness] For some personal viewpoints on this issue, see these
164166
blog posts: `by Hynek Schlawak <semver-hynek-schlawack_>`_, `by Donald Stufft
@@ -176,3 +178,4 @@ since the latest release, setuptools-scm generates a version like
176178
.. _semver-donald-stufft: https://caremad.io/posts/2016/02/versioning-software/
177179
.. _semver-hynek-schlawack: https://hynek.me/articles/semver-will-not-save-you/
178180
.. _setuptools-scm: https://setuptools-scm.readthedocs.io
181+
.. _versions-seth-larson: https://sethmlarson.dev/pep-440

0 commit comments

Comments
 (0)