Normal feature versions would get either zero or at most one bugfix
release; the latter only if needed to fix critical issues.
-.. XXX I think we have to discuss this: it depends on the chosen cycle
- duration (I'd rather have X = 8 and N = 3, and for that it makes
- sense to have bugfix releases IMO.)
LTS versions would get regular bugfix releases until the next LTS
version is out. They then would go into security fixes mode, up to a
termination date at the security release manager's discretion.
The number of release candidates depends, as usual, on the number of
last-minute fixes before final release.
-.. XXX I put in "two alphas"; IMO one alpha is not enough given our
- tendency to shove in things during the alpha period -- also, Nick's
- comments about early alphas apply
The same number of branches would be simultaneously open for regular
maintenance (two until 2.x is terminated, then one).
-.. XXX that is true in your original proposal, but see above
period makes it less cumbersome to interact with contributors of
-.. XXX section "effect on distributions" is missing; but probably that
- can come with the python-dev discussion where the responsibles for
- the different distros can weigh in
+These are open issues that should be worked out during discussion:
+* Decide on X (months between feature releases) and N (feature releases
+ per LTS release) as defined above.
+* For given values of X and N, is the no-bugfix-releases policy for
+ non-LTS versions feasible?
+* Restrict new syntax and similar changes (i.e. everything that was
+ prohibited by PEP 3003) to LTS versions?
+* What is the effect on packagers such as Linux distributions?
A community poll or survey to collect opinions from the greater Python
community would be valuable before making a final decision.