<p dir="ltr"><br>
On 28 May 2015 08:31, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
><br>
> On 28 May 2015 07:48, "Guido van Rossum" <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> ><br>
> > On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> >><br>
> >> On May 27, 2015, at 05:15 PM, Terry Reedy wrote:<br>
> >><br>
> >> >How about a feature release once a year, on a schedule we choose as best for<br>
> >> >us.<br>
> >><br>
> >> We discussed timed releases ages ago and they were rejected by the majority.<br>
> >> Time-based releases can make a lot of sense, especially if the interval is<br>
> >> short enough.  If a feature doesn't make it into the May 2015 release, oh<br>
> >> well, there will be another one in X months.<br>
> >><br>
> >> Ubuntu has had a lot of success with X=6 time-based releases.  That's not to<br>
> >> say there aren't plenty of logistics to work out, or that they are a panacea,<br>
> >> or even that they would work with an all-volunteer developer community.  But<br>
> >> time-based releases do have advantages too, and maybe those would outweigh the<br>
> >> disadvantages for Python at this point.<br>
> ><br>
> ><br>
> > This favors developers (who want to see their feature launched) and early adopters (who want to try out shiny new features).<br>
> ><br>
> > 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.<br>
> ><br>
> > 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).<br>
> ><br>
> > 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?<br>
><br>
> The Linux kernel iterates fairly rapidly, with redistributors agreeing on which versions to target for long term support.<br>
><br>
> Decent overview here: <a href="https://ltsi.linuxfoundation.org/what-is-ltsi">https://ltsi.linuxfoundation.org/what-is-ltsi</a><br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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:</p>
<p dir="ltr">* are we happy increasing that support matrix from 2 versions to 6?<br>
* 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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>