[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

[Nick Coghlan]

On 28 May 2015 07:48, "Guido van Rossum" <guido at python.org> wrote:
>
> On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw <barry at python.org> wrote:
>>
>> On May 27, 2015, at 05:15 PM, Terry Reedy wrote:
>>
>> >How about a feature release once a year, on a schedule we choose as
best for
>> >us.
>>
>> We discussed timed releases ages ago and they were rejected by the
majority.
>> Time-based releases can make a lot of sense, especially if the interval
is
>> short enough.  If a feature doesn't make it into the May 2015 release, oh
>> well, there will be another one in X months.
>>
>> Ubuntu has had a lot of success with X=6 time-based releases.  That's
not to
>> say there aren't plenty of logistics to work out, or that they are a
panacea,
>> or even that they would work with an all-volunteer developer community.
But
>> time-based releases do have advantages too, and maybe those would
outweigh the
>> disadvantages for Python at this point.
>
>
> This favors developers (who want to see their feature launched) and early
adopters (who want to try out shiny new features).
>
> The current system (release every 18-24 months) was established when
users who were decidedly not early adopters started complaining about the
breakneck pace of Python releases.
>
> It's quite possible that the current crop of Python users are less averse
to change (although the conversion rate to Python 3 seems to indicate
otherwise). But it's also hard to compare Ubuntu (which is a roll-up of
thousands of different open-source projects, with a large variety of
different release schedules) to Python (which is a single,
centrally-controlled code base).
>
> What do other projects that are at most 1 order of magnitude smaller or
larger than Python do? E.g. the Linux kernel, or Mysql, or Qt?

The Linux kernel iterates fairly rapidly, with redistributors agreeing on
which versions to target for long term support.

Decent overview here: https://ltsi.linuxfoundation.org/what-is-ltsi

I don't think the comparison really works though, because it's not just
redistributors that are affected, it's alternate implementations of the
language specification, as well as educational materials.

If we got to merge gating on trunk, such that it was feasible to release
3.6dev1 within 6 months of the 3.5 release, then that might be a way of
satisfying both crowds, since it would be a matter of speeding up the
pre-release cycle and increasing the stability expectations for
pre-releases, minimising the ripple effects on other parts of the ecosystem.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150528/a8d5555d/attachment.html>