- several Scientific Python projects are working on a
common version support policy for their projects,
which we need to take into account when considering
changes to our release cadence
- reviewing that draft NEP highlighted several problems
with the way this PEP was using the "major" and "minor"
terms, so this takes a pass through that, replacing
inappropriate uses of "major" with "feature", and
and inapproriate uses of "minor" with "micro"
- I also went through and collected statistics on how many
changes we've been making in micro releases that
warranted version added/changed notes in the docs
* PEP 598: Further discuss testing implications
Also rephrase the section about Python 3.10 vs 4.0
to make it clearer that the PEP isn't *proposing*
releasing 4.0 after 3.9, just discussing the impact
the different choice of version number would have
on the proposal.
* Also propose a tweak to the provisional API policy
- use baseline feature release and incremental feature release
rather than major/minor feature release
- introduce a new "feature_complete" flag on sys.version_info
to allow the branch state to be inspected at runtime
- impose a runtime feature detection requirement on all features
added in incremental feature releases
Alternative to PEP 596 that aims to reduce feature delivery latency
by giving ourselves access to a new, less disruptive, feature
delivery vehicle, rather than by increasing the frequency with
which we deploy our existing disruptive feature delivery vehicle.
Nick Coghlan
Min ho Kim