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

[Nick Coghlan]

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