[Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Stephen J. Turnbull]

Executive summary:

My take is "show us the additional resources, and don't be stingy!"
Sorry, Antoine, I agree with your goals, but I think you are too
optimistic about the positive effects and way too optimistic about the
costs.

Antoine Pitrou writes:

 > Finding a release cycle for an open-source project is a delicate
 > exercise in managing mutually contradicting constraints: developer
 > manpower,

This increases the demand for developer manpower somewhat.

 > availability of release management volunteers,

Dramatic increase here.  It may look like RM is not so demanding --
run a few scripts to put out the alphas/betas/releases.  But the RM
needs to stay on top of breaking news, make decisions.  That takes
time, interrupts other work, etc.

 > ease of maintenance for users and third-party packagers,

Dunno about users, but 3rd party packagers will also have more work to
do, or will have to tell their users "we only promise compatibility
with LTS releases."

 > quick availability of new features (and behavioural changes),

These are already *available*, just not *tested*.

Since testing is the bottleneck on what users consider to be
"available for me", you cannot decrease the amount of testing (alpha,
beta releases) by anywhere near the amount you're increasing
frequency, or you're just producing "as is" snapshots.  Percentage of
time in feature freeze goes way up, features get introduced all at
once just before the next release, schedule slippage is inevitable on
some releases.

 > availability of bug fixes without pulling in new features or
 > behavioural changes.

Sounds like a slight further increase in demand for RM, and as
described a dramatic decrease in the bugfixing for throw-away releases.

 > The current release cycle errs on the conservative side.

What evidence do you have for that, besides people who aren't RMs
wishing that somebody else would do more RM work?

 > More feature releases might mean more stress on the development and
 > release management teams.  This is quantitatively alleviated by the
 > smaller number of pre-release versions; and qualitatively by the
 > lesser amount of disruptive changes (meaning less potential for
 > breakage).

Way optimistic IMO (theoretical, admitted, but I do release management
for a less well-organized project, and I teach in a business school,
FWIW).

 > The shorter feature freeze period (after the first beta build until
 > the final release) is easier to accept.

But you need to look at total time in feature freeze over the LTS
cycle, not just before each throw-away release.

 > The rush for adding features just before feature freeze should also
 > be much smaller.

This doesn't depend on the length of time in feature freeze per
release, it depends on the fraction of time in feature freeze over the
cycle.  Given your quality goals, this will go way up.