The current release cycle errs on the conservative side. It is
adequate for people who value stability over reactivity. This PEP is
an attempt to keep the stability that has become a Python trademark,
-while offering a fluider introduction of features, by introducing the notion
-of long-term support versions.
+while offering a fluider introduction of features, by introducing the
+notion of long-term support versions.
version is out. They then would go into security fixes mode, up to a
termination date at the security release manager's discretion.
-.. XXX we also have to discuss that: it makes LTS no different from
- current feature releases (well indeed they aren't different. It's
- normal releases that are different (AP))
commit bug fixes to the current LTS branch (for example ``3.3``) and
then merge them into ``default``.
-.. XXX handle bug-fixing on non-LTS versions. The original text was wrong:
- If some critical fixes are needed to a non-LTS version, they can be
- committed first to the current LTS branch (e.g. ``3.3``) and then
- merged to the non-LTS branch (e.g. ``3.5``).
- .. XXX no they can't, since that will merge all other fixes too.
- Or the necessary changeset(s) can be grafted manually, at the release
+If some critical fixes are needed to a non-LTS version, they can be
+grafted from the current LTS branch to the non-LTS branch, just like
+fixes are ported from 3.x to 2.7 today.