From 1d7fe02fde6f8d324f066a984a23962916d0c3ee Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Wed, 19 Jun 2024 23:38:53 +0300 Subject: [PATCH 1/5] Update PEP 2026 --- peps/pep-2026.rst | 170 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 167 insertions(+), 3 deletions(-) diff --git a/peps/pep-2026.rst b/peps/pep-2026.rst index e297dca9430..9fdf7658e34 100644 --- a/peps/pep-2026.rst +++ b/peps/pep-2026.rst @@ -14,9 +14,18 @@ Abstract This PEP proposes updating the versioning scheme for Python to include the calendar year. -This aims to make the support lifecycle clear -by making it easy to see when a version was first released, -and easier to work out when it will reach end of life (EOL). + +Calendar Versioning (CalVer) makes *everything* easier to translate into +calendar time rather than counting versions and looking up when they will be +(or were) released: + +* The support lifecycle is clear, + making it easy to see when a version was first released. +* It's easier to work out when a version will reach end of life (EOL). +* Deprecations are easier to manage for maintainers and users. +* It helps people, especially new learners, understand how old their installation. +* It's easier to reason about which versions of Python to support + for libraries and applications. Starting with what would have been Python 3.15, the version is 3.YY.micro where YY is the year of initial release: @@ -219,6 +228,60 @@ it’s much easier: "26 + 5 = [20]31" +Clarity of deprecation removal +------------------------------ + +Warnings for deprecations often mention the version they will be removed in. +For example: + + DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for + removal in Python 3.15 + +However, once aware of CalVer, it is immediately obvious from the warning how +long you have to to take action: + + DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for + removal in Python 3.26 + +Clarity of installation age +--------------------------- + +With the year in the version, it’s easier to work out how old your installation +is. For example, with the current scheme, if you're using Python 3.15 in 2035, +it's not immediately clear that it was first released in 2026 (and has been EOL +since 2031). + +With knowledge of CalVer, if you're using Python 3.26 in 2035, it's clear it was +first released nine years ago and it's probably time to upgrade. + +This can help prompt people to switch to supported releases still under security +support, and help in teaching new users who may have older installations. + +Clarity of version support +-------------------------- + +CalVer makes it easier to reason about which versions of Python to support. + +For example, without CalVer, setting your minimum compatible Python version to +3.19 in 2031 sets an aggressive assumption regarding version adoption and +support. + +However, with CalVer, this is more obvious if setting the minimum to 3.30 in +2031. For wider support, perhaps you prefer setting it to 3.26. + +Similarly, library maintainers supporting all CPython upstream versions +need to test against five versions (or six including the pre-release). + +For example, in 2030, the supported versions without CalVer would be: + +* 3.15, 3.16, 3.17, 3.18, 3.19 + +With CalVer they would be: + +* 3.26, 3.27, 3.28, 3.29, 3.30 + +A maintainer can see at a glance which versions are current and need testing. + Non-goals --------- @@ -329,6 +392,101 @@ be removed in 3.27. | 3.25 | 3.36 | 2036 | +-------------+------------------+-----------------+ +Forwards compatibility +====================== + +Future change in cadence +------------------------ + +This PEP proposes no change to the annual release cadence as defined in +:pep:`602`, which lays out +:pep:`many good reasons for annual releases <602#rationale-and-goals>` +(for example, smaller releases with a predictable release calendar, +and syncing with external redistributors). +However unlikely, should we decide to change the cadence in the future, CalVer +does not preclude doing so. + +Less frequent +''''''''''''' + +If we went to *fewer than one release per year*, the proposed CalVer scheme +still works; indeed, it even helps people know in which year to expect the +release. For example, if we released every second year starting in 2036: + +* 3.36.0 would be released in 2036 +* 3.38.0 would be released in 2038 +* and so on + +Ecosystem changes depend in part on how the the hypothetical cadence-changing +PEP updates :pep:`387` (Backwards Compatibility Policy). If, for example, it +requires that the deprecation period must be at least one feature release and +not the current two (to maintain the minimum two years), CalVer has the benefit +over the status quo in requiring no changes to planned removal versions +(other than adjusting any falling in non-release years). + +.. _PEP 2026 More frequent: + +More frequent +''''''''''''' + +If we went to *more than one release per year*, here are some options. +For example, if we released in April and October starting in 2036, the next +four releases could be: + ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| Scheme | Notes | 2036 a | 2036 b | 2037 a | 2037 b | ++===============+================================+===========+===========+===========+===========+ +| YY.MM.micro | Year as major, month as minor | 36.04.0 | 36.10.0 | 37.04.0 | 37.10.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| YY.x.micro | Year as major, | 36.1.0 | 36.2.0 | 37.1.0 | 37.2.0 | +| | serial number as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YYMM.micro | Combine year and month | 3.3604.0 | 3.3610.0 | 3.3704.0 | 3.3710.0 | +| | as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YYx.micro | Combine year and serial number | 3.360.0 | 3.361.0 | 3.370.0 | 3.371.0 | +| | as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YY.MM.micro | Add an extra month segment | 3.36.04.0 | 3.36.10.0 | 3.37.04.0 | 3.37.10.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.major.micro | No more CalVer: | 3.36.0 | 3.37.0 | 3.38.0 | 3.39.0 | +| | increment minor +-----------+-----------+-----------+-----------+ +| | | 3.50.0 | 3.51.0 | 3.52.0 | 3.53.0 | +| | +-----------+-----------+-----------+-----------+ +| | | 3.100.0 | 3.101.0 | 3.102.0 | 3.103.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 4.major.micro | No more CalVer: | 4.0.0 | 4.1.0 | 4.2.0 | 4.3.0 | ++---------------+ increment major +-----------+-----------+-----------+-----------+ +| 5.major.micro | | 5.0.0 | 5.1.0 | 5.2.0 | 5.3.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ + +The YY options would require addressing issues around the +`platform compatibility tags `__, +the `python3 command `_, and code +`assuming the version always begins with 3 `__. + +The options keeping major version 3 but changing the minor to three or four +digits would also need to address code +`assuming the version is always two digits `__. + +The option adding an extra month segment is the biggest change as code would +need to deal with a four-part version instead of three. + +The options dropping CalVer would be the most conservative +allowing the major and minor to be chosen freely. + +No more CalVer +-------------- + +Adopting CalVer now does not preclude moving away CalVer in the future, +for example, back to the original scheme, to SemVer or another scheme. +Some options are `listed in the table above `__. +If wanting to make it clear the minor is no longer the year, +it can be bumped to a higher round number (for example, 3.50 or 3.100) +or the major version can be bumped (for example, to 4.0 or 5.0). +Additionally, a `version epoch +`__ +could be considered. Security implications ===================== @@ -359,6 +517,8 @@ errors out and tells the user to use ``python3.26`` instead. Rejected ideas ============== +.. _PEP 2026 YY.0: + YY.0 ---- @@ -381,6 +541,8 @@ Will we stick with `version 3 forever Another option would be to put the year in the major version and jump to 26.0. This could mean we could leapfrog all that 4.0 baggage. +.. _PEP 2026 Platform compatibility tags: + Platform compatibility tags ''''''''''''''''''''''''''' @@ -466,6 +628,8 @@ it's still a 3 followed by two digits. `Flake8's flake8-2020 plugin `__ to help find the problems like these. +.. _PEP 2026 python3 command: + ``python3`` command ''''''''''''''''''' From 27cdbcf9b20e992f4fbc2ee6ba8b1f9ef11625ff Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Wed, 10 Jul 2024 12:55:24 +0200 Subject: [PATCH 2/5] Move compatibility after rejected ideas --- peps/pep-2026.rst | 192 +++++++++++++++++++++++----------------------- 1 file changed, 96 insertions(+), 96 deletions(-) diff --git a/peps/pep-2026.rst b/peps/pep-2026.rst index 9fdf7658e34..8049a98385b 100644 --- a/peps/pep-2026.rst +++ b/peps/pep-2026.rst @@ -392,102 +392,6 @@ be removed in 3.27. | 3.25 | 3.36 | 2036 | +-------------+------------------+-----------------+ -Forwards compatibility -====================== - -Future change in cadence ------------------------- - -This PEP proposes no change to the annual release cadence as defined in -:pep:`602`, which lays out -:pep:`many good reasons for annual releases <602#rationale-and-goals>` -(for example, smaller releases with a predictable release calendar, -and syncing with external redistributors). -However unlikely, should we decide to change the cadence in the future, CalVer -does not preclude doing so. - -Less frequent -''''''''''''' - -If we went to *fewer than one release per year*, the proposed CalVer scheme -still works; indeed, it even helps people know in which year to expect the -release. For example, if we released every second year starting in 2036: - -* 3.36.0 would be released in 2036 -* 3.38.0 would be released in 2038 -* and so on - -Ecosystem changes depend in part on how the the hypothetical cadence-changing -PEP updates :pep:`387` (Backwards Compatibility Policy). If, for example, it -requires that the deprecation period must be at least one feature release and -not the current two (to maintain the minimum two years), CalVer has the benefit -over the status quo in requiring no changes to planned removal versions -(other than adjusting any falling in non-release years). - -.. _PEP 2026 More frequent: - -More frequent -''''''''''''' - -If we went to *more than one release per year*, here are some options. -For example, if we released in April and October starting in 2036, the next -four releases could be: - -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| Scheme | Notes | 2036 a | 2036 b | 2037 a | 2037 b | -+===============+================================+===========+===========+===========+===========+ -| YY.MM.micro | Year as major, month as minor | 36.04.0 | 36.10.0 | 37.04.0 | 37.10.0 | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| YY.x.micro | Year as major, | 36.1.0 | 36.2.0 | 37.1.0 | 37.2.0 | -| | serial number as minor | | | | | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| 3.YYMM.micro | Combine year and month | 3.3604.0 | 3.3610.0 | 3.3704.0 | 3.3710.0 | -| | as minor | | | | | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| 3.YYx.micro | Combine year and serial number | 3.360.0 | 3.361.0 | 3.370.0 | 3.371.0 | -| | as minor | | | | | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| 3.YY.MM.micro | Add an extra month segment | 3.36.04.0 | 3.36.10.0 | 3.37.04.0 | 3.37.10.0 | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| 3.major.micro | No more CalVer: | 3.36.0 | 3.37.0 | 3.38.0 | 3.39.0 | -| | increment minor +-----------+-----------+-----------+-----------+ -| | | 3.50.0 | 3.51.0 | 3.52.0 | 3.53.0 | -| | +-----------+-----------+-----------+-----------+ -| | | 3.100.0 | 3.101.0 | 3.102.0 | 3.103.0 | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ -| 4.major.micro | No more CalVer: | 4.0.0 | 4.1.0 | 4.2.0 | 4.3.0 | -+---------------+ increment major +-----------+-----------+-----------+-----------+ -| 5.major.micro | | 5.0.0 | 5.1.0 | 5.2.0 | 5.3.0 | -+---------------+--------------------------------+-----------+-----------+-----------+-----------+ - -The YY options would require addressing issues around the -`platform compatibility tags `__, -the `python3 command `_, and code -`assuming the version always begins with 3 `__. - -The options keeping major version 3 but changing the minor to three or four -digits would also need to address code -`assuming the version is always two digits `__. - -The option adding an extra month segment is the biggest change as code would -need to deal with a four-part version instead of three. - -The options dropping CalVer would be the most conservative -allowing the major and minor to be chosen freely. - -No more CalVer --------------- - -Adopting CalVer now does not preclude moving away CalVer in the future, -for example, back to the original scheme, to SemVer or another scheme. -Some options are `listed in the table above `__. -If wanting to make it clear the minor is no longer the year, -it can be bumped to a higher round number (for example, 3.50 or 3.100) -or the major version can be bumped (for example, to 4.0 or 5.0). -Additionally, a `version epoch -`__ -could be considered. - Security implications ===================== @@ -711,6 +615,102 @@ Change during 3.14 cycle The Python 3.14 release must go ahead because: π. +Forwards compatibility +====================== + +Future change in cadence +------------------------ + +This PEP proposes no change to the annual release cadence as defined in +:pep:`602`, which lays out +:pep:`many good reasons for annual releases <602#rationale-and-goals>` +(for example, smaller releases with a predictable release calendar, +and syncing with external redistributors). +However unlikely, should we decide to change the cadence in the future, CalVer +does not preclude doing so. + +Less frequent +''''''''''''' + +If we went to *fewer than one release per year*, the proposed CalVer scheme +still works; indeed, it even helps people know in which year to expect the +release. For example, if we released every second year starting in 2036: + +* 3.36.0 would be released in 2036 +* 3.38.0 would be released in 2038 +* and so on + +Ecosystem changes depend in part on how the the hypothetical cadence-changing +PEP updates :pep:`387` (Backwards Compatibility Policy). If, for example, it +requires that the deprecation period must be at least one feature release and +not the current two (to maintain the minimum two years), CalVer has the benefit +over the status quo in requiring no changes to planned removal versions +(other than adjusting any falling in non-release years). + +.. _PEP 2026 More frequent: + +More frequent +''''''''''''' + +If we went to *more than one release per year*, here are some options. +For example, if we released in April and October starting in 2036, the next +four releases could be: + ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| Scheme | Notes | 2036 a | 2036 b | 2037 a | 2037 b | ++===============+================================+===========+===========+===========+===========+ +| YY.MM.micro | Year as major, month as minor | 36.04.0 | 36.10.0 | 37.04.0 | 37.10.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| YY.x.micro | Year as major, | 36.1.0 | 36.2.0 | 37.1.0 | 37.2.0 | +| | serial number as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YYMM.micro | Combine year and month | 3.3604.0 | 3.3610.0 | 3.3704.0 | 3.3710.0 | +| | as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YYx.micro | Combine year and serial number | 3.360.0 | 3.361.0 | 3.370.0 | 3.371.0 | +| | as minor | | | | | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.YY.MM.micro | Add an extra month segment | 3.36.04.0 | 3.36.10.0 | 3.37.04.0 | 3.37.10.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 3.major.micro | No more CalVer: | 3.36.0 | 3.37.0 | 3.38.0 | 3.39.0 | +| | increment minor +-----------+-----------+-----------+-----------+ +| | | 3.50.0 | 3.51.0 | 3.52.0 | 3.53.0 | +| | +-----------+-----------+-----------+-----------+ +| | | 3.100.0 | 3.101.0 | 3.102.0 | 3.103.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ +| 4.major.micro | No more CalVer: | 4.0.0 | 4.1.0 | 4.2.0 | 4.3.0 | ++---------------+ increment major +-----------+-----------+-----------+-----------+ +| 5.major.micro | | 5.0.0 | 5.1.0 | 5.2.0 | 5.3.0 | ++---------------+--------------------------------+-----------+-----------+-----------+-----------+ + +The YY options would require addressing issues around the +`platform compatibility tags `__, +the `python3 command `_, and code +`assuming the version always begins with 3 `__. + +The options keeping major version 3 but changing the minor to three or four +digits would also need to address code +`assuming the version is always two digits `__. + +The option adding an extra month segment is the biggest change as code would +need to deal with a four-part version instead of three. + +The options dropping CalVer would be the most conservative +allowing the major and minor to be chosen freely. + +No more CalVer +-------------- + +Adopting CalVer now does not preclude moving away CalVer in the future, +for example, back to the original scheme, to SemVer or another scheme. +Some options are `listed in the table above `__. +If wanting to make it clear the minor is no longer the year, +it can be bumped to a higher round number (for example, 3.50 or 3.100) +or the major version can be bumped (for example, to 4.0 or 5.0). +Additionally, a `version epoch +`__ +could be considered. + Footnotes ========= From a25ec597b686945e466ac3f9c28d2044e0f6949b Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Thu, 11 Jul 2024 14:34:13 +0200 Subject: [PATCH 3/5] Add missing word Co-authored-by: Erlend E. Aasland --- peps/pep-2026.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-2026.rst b/peps/pep-2026.rst index 8049a98385b..462c04dfaca 100644 --- a/peps/pep-2026.rst +++ b/peps/pep-2026.rst @@ -23,7 +23,7 @@ calendar time rather than counting versions and looking up when they will be making it easy to see when a version was first released. * It's easier to work out when a version will reach end of life (EOL). * Deprecations are easier to manage for maintainers and users. -* It helps people, especially new learners, understand how old their installation. +* It helps people, especially new learners, understand how old their installation is. * It's easier to reason about which versions of Python to support for libraries and applications. From edfa46aa8c6f92f5dce6076189d4eb8822417740 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Thu, 11 Jul 2024 16:47:45 +0200 Subject: [PATCH 4/5] Also move the other compatibility after rejected ideas --- peps/pep-2026.rst | 98 +++++++++++++++++++++++------------------------ 1 file changed, 49 insertions(+), 49 deletions(-) diff --git a/peps/pep-2026.rst b/peps/pep-2026.rst index 462c04dfaca..acc69e3cccb 100644 --- a/peps/pep-2026.rst +++ b/peps/pep-2026.rst @@ -343,55 +343,6 @@ Python 3.14 will be the last version before this change, released in 2025. Python 3.26 will be the first version after this change, released in 2026. There will be no Python 3.15 to 3.25 inclusive. -Backwards compatibility -======================= - -This version change is the safest of the CalVer options considered -(see `rejected ideas `_): we keep 3 as the major version, -and the minor version is still two digits. -The minor will eventually change to three digits but this is predictable, -a long way off and can be planned for. - -We retain the ``python3`` executable. - -Version mapping ---------------- - -Versions 3.15 to 3.25 inclusive will be skipped. -Features, deprecations and removals planned for these will be remapped to the -new version numbers. - -For example, a deprecation initially planned for removal in 3.16 will instead -be removed in 3.27. - -+-------------+------------------+-----------------+ -| Old version | New version | Initial release | -+=============+==================+=================+ -| 3.14 | 3.14 (no change) | 2025 | -+-------------+------------------+-----------------+ -| 3.15 | 3.26 | 2026 | -+-------------+------------------+-----------------+ -| 3.16 | 3.27 | 2027 | -+-------------+------------------+-----------------+ -| 3.17 | 3.28 | 2028 | -+-------------+------------------+-----------------+ -| 3.18 | 3.29 | 2029 | -+-------------+------------------+-----------------+ -| 3.19 | 3.30 | 2030 | -+-------------+------------------+-----------------+ -| 3.20 | 3.31 | 2031 | -+-------------+------------------+-----------------+ -| 3.21 | 3.32 | 2032 | -+-------------+------------------+-----------------+ -| 3.22 | 3.33 | 2033 | -+-------------+------------------+-----------------+ -| 3.23 | 3.34 | 2034 | -+-------------+------------------+-----------------+ -| 3.24 | 3.35 | 2035 | -+-------------+------------------+-----------------+ -| 3.25 | 3.36 | 2036 | -+-------------+------------------+-----------------+ - Security implications ===================== @@ -615,6 +566,55 @@ Change during 3.14 cycle The Python 3.14 release must go ahead because: π. +Backwards compatibility +======================= + +This version change is the safest of the CalVer options considered +(see `rejected ideas `_): we keep 3 as the major version, +and the minor version is still two digits. +The minor will eventually change to three digits but this is predictable, +a long way off and can be planned for. + +We retain the ``python3`` executable. + +Version mapping +--------------- + +Versions 3.15 to 3.25 inclusive will be skipped. +Features, deprecations and removals planned for these will be remapped to the +new version numbers. + +For example, a deprecation initially planned for removal in 3.16 will instead +be removed in 3.27. + ++-------------+------------------+-----------------+ +| Old version | New version | Initial release | ++=============+==================+=================+ +| 3.14 | 3.14 (no change) | 2025 | ++-------------+------------------+-----------------+ +| 3.15 | 3.26 | 2026 | ++-------------+------------------+-----------------+ +| 3.16 | 3.27 | 2027 | ++-------------+------------------+-----------------+ +| 3.17 | 3.28 | 2028 | ++-------------+------------------+-----------------+ +| 3.18 | 3.29 | 2029 | ++-------------+------------------+-----------------+ +| 3.19 | 3.30 | 2030 | ++-------------+------------------+-----------------+ +| 3.20 | 3.31 | 2031 | ++-------------+------------------+-----------------+ +| 3.21 | 3.32 | 2032 | ++-------------+------------------+-----------------+ +| 3.22 | 3.33 | 2033 | ++-------------+------------------+-----------------+ +| 3.23 | 3.34 | 2034 | ++-------------+------------------+-----------------+ +| 3.24 | 3.35 | 2035 | ++-------------+------------------+-----------------+ +| 3.25 | 3.36 | 2036 | ++-------------+------------------+-----------------+ + Forwards compatibility ====================== From 0e16138edda92fb5b094400aa3468e1070049c14 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Thu, 11 Jul 2024 17:25:55 +0200 Subject: [PATCH 5/5] Reorder --- peps/pep-2026.rst | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/peps/pep-2026.rst b/peps/pep-2026.rst index acc69e3cccb..913e062d1d3 100644 --- a/peps/pep-2026.rst +++ b/peps/pep-2026.rst @@ -21,8 +21,8 @@ calendar time rather than counting versions and looking up when they will be * The support lifecycle is clear, making it easy to see when a version was first released. -* It's easier to work out when a version will reach end of life (EOL). * Deprecations are easier to manage for maintainers and users. +* It's easier to work out when a version will reach end of life (EOL). * It helps people, especially new learners, understand how old their installation is. * It's easier to reason about which versions of Python to support for libraries and applications. @@ -210,6 +210,21 @@ and encode the year in the minor version: For example, 3.26 will be released in 2026. It makes it obvious when a release first came out. +Clarity of deprecation removal +------------------------------ + +Warnings for deprecations often mention the version they will be removed in. +For example: + + DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for + removal in Python 3.15 + +However, once aware of CalVer, it is immediately obvious from the warning how +long you have to to take action: + + DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for + removal in Python 3.26 + Clarity of support lifecycle ---------------------------- @@ -228,21 +243,6 @@ it’s much easier: "26 + 5 = [20]31" -Clarity of deprecation removal ------------------------------- - -Warnings for deprecations often mention the version they will be removed in. -For example: - - DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for - removal in Python 3.15 - -However, once aware of CalVer, it is immediately obvious from the warning how -long you have to to take action: - - DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for - removal in Python 3.26 - Clarity of installation age ---------------------------