Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 6 July 2016 at 11:09, Barry Warsaw wrote: > On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote: > >>However, if we did decide we wanted to take minimising "time to >>redistribution" for at least Ubuntu & Fedora into account, then the >>two main points to consider would be: >>

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Jul 06, 2016, at 10:55 AM, Nick Coghlan wrote: >However, if we did decide we wanted to take minimising "time to >redistribution" for at least Ubuntu & Fedora into account, then the >two main points to consider would be: > >- starting the upstream beta phase before the first downstream alpha

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Jul 06, 2016, at 10:02 AM, Nick Coghlan wrote: >On 6 July 2016 at 03:44, Barry Warsaw wrote: > >> Projecting ahead, it probably means 3.7 in mid-2018, which is after the >> Ubuntu 18.04 LTS release, so we'll only do one major transition before the >> next LTS. From my

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 6 July 2016 at 05:11, Brett Cannon wrote: > Sticking w/ 18 months is also fine, but then I would like to discuss > choosing what months we try to release to get into a date-based release > cadence so we know that every e.g. December and June are when releases > typically

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 6 July 2016 at 03:44, Barry Warsaw wrote: > For example, 3.6 final will come out in December 2016, so it'll be past our > current 16.10 Ubuntu release. We've pretty much decided to carry Python 3.5 > through until 17.04, and that'll give us a good year to make 18.04 LTS have

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Tue, 5 Jul 2016 at 10:45 Barry Warsaw wrote: > On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote: > > >While we liked the "consistent calendar cadence that is some multiple > >of 6 months" idea, several of us thought 12 months was way too short > >as it makes for too many

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote: >While we liked the "consistent calendar cadence that is some multiple >of 6 months" idea, several of us thought 12 months was way too short >as it makes for too many entries in third party support matrices. 18 months for a major release cadence

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3, release)

On 07/03/2016 09:39 AM, Guido van Rossum wrote: Do releases really have to be such big productions? A recent ACM article by Tom Limoncelli[1] reminded me that we're doing releases the old-fashioned way -- infrequently, and with lots of manual labor. Maybe we could (eventually) try to strive

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 4 July 2016 at 06:22, Brett Cannon wrote: > [forking the conversation since the subject has shifted] > > On Sun, 3 Jul 2016 at 09:50 Steve Dower wrote: >> >> Many of our users prefer stability (the sort who plan operating system >> updates years in

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

I actually thought about Rust when thinking about 3 month releases (I know they release faster though). What i would want to know is whether the RMs for Rust are employed by Mozilla and thus have work time to do but it vs Python RMs & friends who vary ob whether they get work time. On Sun, Jul 3,

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Sun, Jul 3, 2016, 14:22 Paul Moore wrote: > On 3 July 2016 at 22:04, Brett Cannon wrote: > > This last bit is what I would advocate if we broke the stdlib out unless > an > > emergency patch release is warranted for a specific module (e.g. like > >

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Jul 3, 2016 1:45 PM, "Paul Moore" wrote: > [...] > Furthermore, pip/setuptools are just getting to the point of allowing > for dependencies conditional on Python version. If independent stdlib > releases were introduced, we'd need to implement dependencies based on >

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 3 July 2016 at 22:04, Brett Cannon wrote: > This last bit is what I would advocate if we broke the stdlib out unless an > emergency patch release is warranted for a specific module (e.g. like > asyncio that started this discussion). Obviously backporting is its own > thing.

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Sun, Jul 3, 2016, 13:43 Paul Moore wrote: > On 3 July 2016 at 21:22, Brett Cannon wrote: > > Topic 2 > > === > > Independent releases of the stdlib could be done, although if we break > the > > stdlib up into individual repos then it shifts the

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

As an observer and user— It may be worth asking the Rust team what the main pain points are in coordinating and managing their releases. Some context for those unfamiliar: Rust uses a Chrome- or Firefox-like release train approach, with stable and beta releases every six weeks. Each release

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On 3 July 2016 at 21:22, Brett Cannon wrote: > Topic 2 > === > Independent releases of the stdlib could be done, although if we break the > stdlib up into individual repos then it shifts the conversation as > individual modules could simply do their own releases independent

[Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

[forking the conversation since the subject has shifted] On Sun, 3 Jul 2016 at 09:50 Steve Dower wrote: > Many of our users prefer stability (the sort who plan operating system > updates years in advance), but generally I'm in favour of more frequent > releases. > So