* proposes the regular publication of production-ready beta releases rather than making full X.Y.0 feature releases more common
* PEP 598 is being withdrawn in favour of this proposal
* originally drafted in collaboration with @zooba, @aeros167, and @h-vetinari
The PEP's previous handling of the micro version compatibility
testing question really wasn't very good, and didn't address the
question of pickle compatibility at all.
So if this idea is going to be considered seriously, it needs
to provide a way to explicitly opt out of the feature additions,
without having to downgrade back to an earlier point release.
- 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