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

Stephen J. Turnbull stephen at xemacs.org
Wed Jan 18 03:37:08 CET 2012

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.

More information about the Python-Dev mailing list