@@ -16,18 +16,18 @@ needs of that particular project, but in order to be compatible with tools like
16
16
:ref: `pip `, all of them are required to comply with a flexible format for
17
17
version identifiers, for which the authoritative reference is the
18
18
: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 ``
31
31
32
32
Projects can use a cycle of pre-releases to support testing by their users
33
33
before a final release. In order, the steps are: alpha releases, beta releases,
@@ -68,11 +68,11 @@ Semantic versioning
68
68
-------------------
69
69
70
70
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:
72
72
73
73
- *major * when they make incompatible API changes,
74
74
- *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.
76
76
77
77
A majority of Python projects use a scheme that resembles semantic
78
78
versioning. However, most projects, especially larger ones, do not strictly
@@ -159,6 +159,8 @@ since the latest release, setuptools-scm generates a version like
159
159
160
160
--------------------------------------------------------------------------------
161
161
162
+ .. [#version-examples ] Some more examples of unusual version numbers are
163
+ given in a `blog post <versions-seth-larson >`_ by Seth Larson.
162
164
163
165
.. [#semver-strictness ] For some personal viewpoints on this issue, see these
164
166
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
176
178
.. _semver-donald-stufft : https://caremad.io/posts/2016/02/versioning-software/
177
179
.. _semver-hynek-schlawack : https://hynek.me/articles/semver-will-not-save-you/
178
180
.. _setuptools-scm : https://setuptools-scm.readthedocs.io
181
+ .. _versions-seth-larson : https://sethmlarson.dev/pep-440
0 commit comments