Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify definition of "minor" vs "major" release #105844

Closed
jamestwebber opened this issue Jun 16, 2023 · 4 comments
Closed

Clarify definition of "minor" vs "major" release #105844

jamestwebber opened this issue Jun 16, 2023 · 4 comments
Labels
docs Documentation in the Doc dir

Comments

@jamestwebber
Copy link
Contributor

jamestwebber commented Jun 16, 2023

Documentation

I noticed this in a discussion but it was off-topic there. Either I'm misreading things, but it seems like the definition of major and minor release is inconsistent in the documentation. See this page (bold mine):

Python’s C API is covered by the Backwards Compatibility Policy, PEP 387. While the C API will change with every minor release (e.g. from 3.9 to 3.10), most changes will be source-compatible, typically by only adding new API. Changing existing API or removing API is only done after a deprecation period or to fix serious issues.

CPython’s Application Binary Interface (ABI) is forward- and backwards-compatible across a minor release (if these are compiled the same way; see Platform Considerations below). So, code compiled for Python 3.10.0 will work on 3.10.8 and vice versa, but will need to be compiled separately for 3.9.x and 3.10.x.

Here, the 11 in 3.11 is referred to as a minor release: the API can change when that changes, but within such a release it should be stable.

In other parts of Python documentation, most notably python.org, 3.11 (or 3.10, etc) is referred to as a "major release".

The FAQ is less than clear on this (again bold mine):

How does the Python version numbering scheme work?
Python versions are numbered “A.B.C” or “A.B”:

  • A is the major version number – it is only incremented for really major changes in the language.
  • B is the minor version number – it is incremented for less earth-shattering changes.
  • C is the micro version number – it is incremented for each bugfix release.

See PEP 6 for more information about bugfix releases.

Not all releases are bugfix releases. In the run-up to a new major release, a series of development releases are made, denoted as alpha, beta, or release candidate. Alphas are early releases in which interfaces aren’t yet finalized; it’s not unexpected to see an interface change between two alpha releases. Betas are more stable, preserving existing interfaces but possibly adding new modules, and release candidates are frozen, making no changes except as needed to fix critical bugs.

Most of the time this is not a big concern but particularly for statements about long-term compatibility (like the C API page above) I think this is rather confusing.

Linked PRs

@erlend-aasland
Copy link
Contributor

erlend-aasland commented Jun 16, 2023

Most of the time this is not a big concern but particularly for statements about long-term compatibility (like the C API page above) I think this is rather confusing.

I don't follow; I cannot not find any version inconsistencies on https://docs.python.org/3/c-api/stable.html. As far as I can see, minor version is used consistently there.

The FAQ is slightly inconsistent, though. Perhaps PEP-602 also needs an update1.

Footnotes

  1. PEP issues must be reported to https://github.com/python/peps; python.org inconsistencies at https://github.com/python/pythondotorg)

erlend-aasland added a commit to erlend-aasland/cpython that referenced this issue Jun 16, 2023
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 16, 2023
…ythonGH-105851)

(cherry picked from commit 0bffe1a)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 16, 2023
…ythonGH-105851)

(cherry picked from commit 0bffe1a)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
@erlend-aasland
Copy link
Contributor

erlend-aasland added a commit that referenced this issue Jun 16, 2023
…H-105851) (#105853)

(cherry picked from commit 0bffe1a)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
erlend-aasland added a commit that referenced this issue Jun 16, 2023
…H-105851) (#105852)

(cherry picked from commit 0bffe1a)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
@jamestwebber
Copy link
Contributor Author

I don't follow; I cannot not find any version inconsistencies on https://docs.python.org/3/c-api/stable.html. As far as I can see, minor version is used consistently there.

The FAQ is slightly inconsistent, though. Perhaps PEP-602 also needs an update.

Yeah I just meant it was confusing to me when looking across multiple places. In particular the announcement of new releases got me used to thinking of them as "major". Thanks for the updates!

carljm added a commit to carljm/cpython that referenced this issue Jun 16, 2023
* main:
  pythongh-104799: PEP 695 backward compatibility for ast.unparse (python#105846)
  pythongh-105834: Add tests for calling `issubclass()` between two protocols (python#105835)
  CI: Remove docs build from Azure Pipelines (python#105823)
  pythongh-105844: Consistently use 'minor version' for X.Y versions (python#105851)
  Fix inaccuracies in "Assorted Topics" section of "Defining Extension Types" tutorial (python#104969)
  pythongh-105433: Add `pickle` tests for PEP695 (python#105443)
  bpo-44530: Document the change in MAKE_FUNCTION behavior (python#93189)
  pythonGH-103124: Multiline statement support for pdb (pythonGH-103125)
  pythonGH-105588: Add missing error checks to some obj2ast_* converters (pythonGH-105589)
@erlend-aasland
Copy link
Contributor

erlend-aasland commented Jun 17, 2023

See @CAM-Gerlach's review of python/peps#3174 (python/peps#3174 (review)). I see now that my docs update could be made even clearer, by using the established release naming convention used in the devguide. 3.11 and 3.12 are feature releases, not minor releases.

erlend-aasland added a commit to erlend-aasland/cpython that referenced this issue Jun 17, 2023
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 18, 2023
…H-105882)

(cherry picked from commit dba7217)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 18, 2023
…H-105882)

(cherry picked from commit dba7217)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
erlend-aasland added a commit that referenced this issue Jun 18, 2023
) (#105893)

(cherry picked from commit dba7217)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
erlend-aasland added a commit that referenced this issue Jun 18, 2023
) (#105892)

(cherry picked from commit dba7217)

Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
@CAM-Gerlach CAM-Gerlach changed the title definition of "minor" vs "major" release Clarify definition of "minor" vs "major" release Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

No branches or pull requests

2 participants