Re: [python-committers] Pace of change for Python 3.x

On Wed, 25 Jan 2017 at 06:29 M.-A. Lemburg wrote: > On 25.01.2017 13:30, Antoine Pitrou wrote: > > > > Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit : > >> All that said, I believe a having a Python 2.7 style long > >> support version for Python 3 would be nice and have a stabilizing > >> effect w

Re: [python-committers] Pace of change for Python 3.x

On 2017-01-25, A.M. Kuchling wrote: > I think this is the next frontier for Python maintenance; we need > full-time core maintainers, no third parties are funding any such > developers, and the PSF doesn't seem interested in pursuing that. IMHO, the PSF should be doing it. I don't know exactly ho

Re: [python-committers] Pace of change for Python 3.x

On Wed, 25 Jan 2017 at 06:11 A.M. Kuchling wrote: > On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote: > > Channeling Nick, I'd say that LTS support should come from commercial > third > > parties, such as OS vendors. I agree with Antoine: it's not something we > > want to impose on t

[python-committers] Update PEP-373: Release schedule for Python 2.7

doesn't have the release date of 2.7.13 (already done) neither the scheduled date for 2.7.14. I could Pull Request the first, but I don't know about the second... -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es -

Re: [python-committers] Pace of change for Python 3.x

On Jan 25, 2017, at 07:45 AM, Eric V. Smith wrote: >Channeling Nick, I'd say that LTS support should come from commercial third >parties, such as OS vendors. I agree with Antoine: it's not something we want >to impose on the core devs. How much fun is 2.7 maintenance? Which effectively happens an

Re: [python-committers] Pace of change for Python 3.x

On 25.01.2017 13:30, Antoine Pitrou wrote: > > Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit : >> All that said, I believe a having a Python 2.7 style long >> support version for Python 3 would be nice and have a stabilizing >> effect which our user base would appreciate. > > Trying to enforce suc

Re: [python-committers] Pace of change for Python 3.x

On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote: > Channeling Nick, I'd say that LTS support should come from commercial third > parties, such as OS vendors. I agree with Antoine: it's not something we > want to impose on the core devs. How much fun is 2.7 maintenance? Are there any

Re: [python-committers] Pace of change for Python 3.x

On 25 January 2017 at 12:45, Eric V. Smith wrote: > Channeling Nick, I'd say that LTS support should come from commercial third > parties, such as OS vendors. I agree with Antoine: it's not something we > want to impose on the core devs. How much fun is 2.7 maintenance? Agreed. When lack of revie

Re: [python-committers] Pace of change for Python 3.x

On 1/25/2017 7:30 AM, Antoine Pitrou wrote: We'd just say: this is our new LTS release (e.g. Python 3.7) and then move on until we're confident again that the feature set has stabilized enough to create a new LTS release. In practice you wouldn't just "move on" but have to maintain that LTS rel

Re: [python-committers] Pace of change for Python 3.x

Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit : >> >> You should take a look at this old deferred PEP: >> https://www.python.org/dev/peps/pep-0407/ > > I don't understand the reasoning behind that PEP. With the proposed > timing, those "LTS" releases would be no different than what we have > today

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

On 24.01.2017 22:08, Victor Stinner wrote: > 2017-01-24 21:46 GMT+01:00 Neil Schemenauer : >> Maybe we could emulate the Linux kernel releases. I.e. have >> relatively fast moving development but also choose releases to give >> long maintenance cycles. Ideally the long term releases would be >> s