[Python-Dev] whither PEP 407 and 413 (release cycle PEPs)? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Jun 3 23:02:52 CEST 2012

On Sun, Jun 3, 2012 at 9:22 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

On 01.06.2012 19:33, Brett Cannon wrote:

Are these dead in the water or are we going to try to change our release cycle? I'm just asking since 3.3 final is due out in about 3 months and deciding on this along with shifting things if we do make a change could end up taking that long and I suspect if we don't do this for 3.3 we are probably never going to do it for Python 3 series as a whole. I'm -1 on both PEPs.

Unsurprisingly, I'm -1 on PEP 407. Perhaps surprisingly, I'm also -0 on my own PEP 413 (I wrote it to present what I consider a more tolerable alternative to an idea I really don't like)

I think marking both as Rejected would be an accurate reflection of python-dev's collective opinion.

For PEP 413, much the same concerns apply. In addition, I think it's too complicated, both for users, and for the actual technical implementation.

Yup (although I think PEP 407 would need to be at least as complicated in practice as PEP 413 in order to make the implementation manageable, but currently glosses over the technical details).

The one thing I actually would like to see change is for the cadence of alpha releases to be increased to match that of maintenance releases (that is, I'd like to see Python 3.4a1 released at the same time as Python 3.3.1: around 6 months after the release of 3.3.0). I think keeping the trunk closer to a "releasable" state will help encourage a more regular rate of contributions and provide earlier deadlines for big changes (e.g. it's significantly easier to say "we want to have the compiler changes in place for 3.4a1 in April" than it is to say "we want to have these changes in place by April, but that's just an arbitrary point in time, since the nearest release deadline will still be at least 12 months away". Scheduling things like sprints and bug days also becomes more focused, since they have a nearer term goal of getting things fixed for an alpha release that's only a few months away rather than one that's more than a year out).

It also lowers the bar for getting people to tinker with and provide feedback on new syntax like PEP 380 and core features like pyvenv and pysetup that behave differently when installed instead of being run from a source checkout. At the moment, the criteria for providing early feedback on new syntax is "interested in the feature, and can build CPython from source", while the criteria for installed features is "interested in the feature, can build CPython from source, and can install the result on a target system". Early alphas means that the criteria for providing feedback becomes simply: "interested in the feature, and has access to a system that can tolerate having the alpha release installed".

These alpha releases can also feed into vendor schemes such as Red Hat's tech preview program: while the system Python would always be a released version, an alpha version may still be an adequate foundation for a tech preview. As the other Python implementations catch up to the 3.x series, the alphas would also provide clear recommended synchronisation points that may make it easier for them to start targeting CPython release compatibility before we publish the final version.

As I see it, such an approach would achieve most of the benefits of a regular release cadence with basically none of the seriously disruptive effects created by the more ambitious schemes described in PEP 407 or 413. I also consider it an excellent test run: if we can't even produce alpha releases of the upcoming version every 6 months or so, how on earth could we ever consider trying to create production releases on that schedule?

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list