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

[Nick Coghlan]

On 28 May 2015 08:31, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
>
> 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.

I just remembered one of the biggest causes of pain: Windows binaries for
projects that aren't using the stable ABI. It used to regularly take 6+
months for the Windows ecosystem to catch up after each 2.x release.

Since community  project version compatibility time spans tend to be on the
order of 3 years (exceptional cases like 2.6 & 2.7 aside), we need to
consider:

* are we happy increasing that support matrix from 2 versions to 6?
* if we tell third party community projects to only test against and
provide prebuilt binaries for the less frequent LTS releases, how useful
would they really be over switching from the current alpha/beta/rc
pre-release cycle to a time based merge gated dev release cycle followed by
a beta/rc cycle?

After all, the real difference between the alphas and the final releases
isn't about anything *we* do, it's about the testing *other people* do that
picks up gaps in our test coverage. A gated trunk makes it more feasible
for other projects to do continuous integration against it.

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