On 2021-10-16 22:39, Oscar Benjamin wrote:
On Fri, 15 Oct 2021 at 14:12, Petr Viktorin encukou@gmail.com wrote:
Most of this is, hopefully, just capturing existing tribal knowledge, but:
[snip]
Micro Versions
A new micro version marks *bugfix* and *security* releases. These releases are managed for stability; only fixes for known problems are included in them, and Python's interfaces do not change in new micro versions.
Generally, it is enough for third-party libraries to test with one release of a minor version -- ideally the latest one. For example, a library tested with Python 3.5.10 may reasonably claim to be compatible with Python 3.5 in general.
I would just like to note that in SymPy we had problems a few times because of changes made to typing in the 3.5.x series. The problem was that CI tested the newest version of 3.5.x but many users were using older versions and many features were added in micro releases e.g. (random example from docs) typing.NoReturn has:
New in version 3.5.4. New in version 3.6.2.
What that meant is that if a contributor had used NoReturn as a type hint then because SymPy's CI only tested the most recent 3.5.x it would not be noticed in PR review that SymPy had become unimportable in 3.5.0.
This was not a major problem: where I saw complaints it seemed that users were happy to upgrade to a newer Python 3.5.x. In general though those changes do not match the explanation shown above. I welcome the documentation around what kind of changes will be made in different releases but just to be clear, should this preclude things like adding typing.NoReturn in micro releases? (I hope so.)
Wasn't there a change in a micro version of Python 2? I can't remember the details, but from hindsight it was seen as a mistake that should not be repeated.