Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 20 January 2012 03:57, Brian Curtin br...@python.org wrote: FWIW, it might well be that I can't be available for the 3.3 final release (I haven't finalized my vacation schedule yet for August). In the interest of not having Windows releases depend on one person, and having gone through building the installer myself (which I know is but one of the duties), I'm available to help should you need it. One thought comes to mind - while we need a PEP to make a permanent change to the release schedule, would it be practical in any way to do a trial run of the process, and simply aim to release 3.4 about 6 months after 3.3? Based on the experiences gained from that, some of the discussions around this PEP could be supported (or not :-)) with more concrete information. If we can't do that, then that says something about the practicality of the proposal in itself... The plan for 3.4 would need to be publicised well in advance, of course, but doing that as a one-off exercise might well be viable. Paul. PS I have no view on whether the proposal is a good idea or a bad idea from a RM point of view. That's entirely up to the people who do the work to decide, in my opinion. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Fri, 20 Jan 2012 12:57:45 + Paul Moore p.f.mo...@gmail.com wrote: On 20 January 2012 03:57, Brian Curtin br...@python.org wrote: FWIW, it might well be that I can't be available for the 3.3 final release (I haven't finalized my vacation schedule yet for August). In the interest of not having Windows releases depend on one person, and having gone through building the installer myself (which I know is but one of the duties), I'm available to help should you need it. One thought comes to mind - while we need a PEP to make a permanent change to the release schedule, would it be practical in any way to do a trial run of the process, and simply aim to release 3.4 about 6 months after 3.3? It sounds reasonable to me, although we probably wouldn't market it as a trial run. cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 20.01.2012 00:54, schrieb Martin v. Löwis: I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). Thanks for the reminder, Martin. Even with the current release schedule, I think that the load on you is too much, and we need a whole team of Windows release experts. It's not really fair that the RM usually changes from release to release (at least every 2), and you have to do the same for everyone. It looks like we have one volunteer already; if we find another, I think one of them will also be not on vacation at most times :) For the Mac, at least we're up to two experts, but I'd like to see a third there too. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 20/01/2012 19:14, Georg Brandl wrote: Am 20.01.2012 00:54, schrieb Martin v. Löwis: I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). Thanks for the reminder, Martin. Even with the current release schedule, I think that the load on you is too much, and we need a whole team of Windows release experts. It's not really fair that the RM usually changes from release to release (at least every 2), and you have to do the same for everyone. It looks like we have one volunteer already; if we find another, I think one of them will also be not on vacation at most times :) I'm certainly happy to help out there. Like everyone I'm not always clear on my availability but the more people who know what needs to be done, the better ISTM. TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 20.01.2012 21:08, schrieb Tim Golden: On 20/01/2012 19:14, Georg Brandl wrote: Am 20.01.2012 00:54, schrieb Martin v. Löwis: I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). Thanks for the reminder, Martin. Even with the current release schedule, I think that the load on you is too much, and we need a whole team of Windows release experts. It's not really fair that the RM usually changes from release to release (at least every 2), and you have to do the same for everyone. It looks like we have one volunteer already; if we find another, I think one of them will also be not on vacation at most times :) I'm certainly happy to help out there. Like everyone I'm not always clear on my availability but the more people who know what needs to be done, the better ISTM. Definitely. Thanks for volunteering, Tim! Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Thu, 19 Jan 2012 11:12:06 +1100 Steven D'Aprano st...@pearwood.info wrote: Antoine Pitrou wrote: Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit : You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. Surely testing is related to user perceptions of stability. More testing helps reduce bugs in released software, which improves user perception of stability, encouraging them to use the software in production. I have asked a practical question, a theoretical answer isn't exactly what I was waiting for. [...] I don't care to convince *you*, since you are not involved in Python development and release management (you haven't ever been a contributor AFAIK). Unless you produce practical arguments, saying I don't think you can do it is plain FUD and certainly not worth answering to. Pardon me, but people like Stephen Turnbull are *users* of Python, exactly the sort of people you DO have to convince that moving to an accelerated or more complex release process will result in a better product. The risk is that you will lose users, or fragment the user base even more than it is now with 2.x vs 3.x. Well, you might bring some examples here, but I haven't seen any project lose users *because* they switched to a faster release cycle (*). I don't understand why this proposal would fragment the user base, either. We're not proposing to drop compatibility or build Python 4. ((*) Firefox's decrease in popularity seems to be due to Chrome uptake, and their new release cycle is arguably in response to that) Quite frankly, I like the simplicity and speed of the current release cycle. All this talk about separate LTS releases and parallel language releases and library releases makes my head spin. Well, the PEP discussion might make your head spin, because various possibilities are explored. Obviously the final solution will have to be simple enough to be understood by anyone :-) (do you find Ubuntu's release model, for example, too complicated?) I fear the day that people asking questions on the tutor or python-list mailing lists will have to say (e.g.) I'm using Python 3.4.1 and standard library 1.2.7 in order to specify the version they're using. Yeah, that's my biggest problem with Nick's proposal. Hopefully we can avoid parallel version schemes. You're hoping that a more rapid release cycle will attract more developers, and there is a chance that you could be right; but a more rapid release cycle WILL increase the total work load. So you're betting that this change will attract enough new developers that the work load per person will decrease even as the total work load increases. This is not something that we can find out without trying, I think. As Georg pointed out, the decision is easy to revert or amend if we find out that the new release cycle is unworkable. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Thu, Jan 19, 2012 at 9:07 PM, Antoine Pitrou solip...@pitrou.net wrote: I fear the day that people asking questions on the tutor or python-list mailing lists will have to say (e.g.) I'm using Python 3.4.1 and standard library 1.2.7 in order to specify the version they're using. Yeah, that's my biggest problem with Nick's proposal. Hopefully we can avoid parallel version schemes. They're not really parallel - the stdlib version would fully determine the language version. I'm only proposing two version numbers because we're planning to start versioning *two* things (the standard library, updated every 6 months, and the language spec, updated every 18-24 months). Since the latter matches what we do now, I'm merely proposing that we leave its versioning alone, and add a *new* identiifier specifically for the interim stdlib updates. Thinking about it though, I've realised that the sys.version string already contains a lot more than just the language version number, so I think it should just be updated to include the stdlib version information, and the version_info named tuple could get a new 'stdlib' field as a string. That way, sys.version and sys.version_info would still fully define the Python version, we just wouldn't be mucking with the meaning of any of the existing fields. For example, the current: sys.version '3.2.2 (default, Sep 5 2011, 21:17:14) \n[GCC 4.6.1]' sys.version_info sys.version_info(major=3, minor=2, micro=2, releaselevel='final', serial=0) might become: sys.version '3.3.1 (stdlib 12.08, default, Feb 18 2013, 21:17:14) \n[GCC 4.6.1]' sys.version_info sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0, stdlib='12.08') for the maintenance release and: sys.version '3.3.1 (stdlib 13.02, default, Feb 18 2013, 21:17:14) \n[GCC 4.6.1]' sys.version_info sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0, stdlib='13.02') for the stdlib-only update. Explicit-is-better-than-implicit'ly yours, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 19.01.2012 01:12, schrieb Steven D'Aprano: One on-going complaint is that Python-Dev doesn't have the manpower or time to do everything that needs to be done. Bugs languish for months or years because nobody has the time to look at it. Will going to a more rapid release cycle give people more time, or just increase their workload? You're hoping that a more rapid release cycle will attract more developers, and there is a chance that you could be right; but a more rapid release cycle WILL increase the total work load. So you're betting that this change will attract enough new developers that the work load per person will decrease even as the total work load increases. I don't think that's a safe bet. I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... That is, I don't want to exclude you from the discussion, but on the issue of workload I would like to encourage more of our (past and present) release managers and active bug triagers to weigh in. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). FWIW, it might well be that I can't be available for the 3.3 final release (I haven't finalized my vacation schedule yet for August). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Fri, Jan 20, 2012 at 9:54 AM, Martin v. Löwis mar...@v.loewis.de wrote: I can't help noticing that so far, worries about the workload came mostly from people who don't actually bear that load (this is no accusation!), while those that do are the proponents of the PEP... Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). I must admit that aspect had concerned me as well. Currently we use the 18-24 month window for releases to slide things around to accommodate the schedules of the RM, Martin (Windows binaries) and Ned/Ronald (Mac OS X binaries). Before we could realistically switch to more frequent releases, something would need to change on the binary release side. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Thu, Jan 19, 2012 at 17:54, Martin v. Löwis mar...@v.loewis.de wrote: Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). FWIW, it might well be that I can't be available for the 3.3 final release (I haven't finalized my vacation schedule yet for August). In the interest of not having Windows releases depend on one person, and having gone through building the installer myself (which I know is but one of the duties), I'm available to help should you need it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Wed, 18 Jan 2012 07:52:20 + Paul Moore p.f.mo...@gmail.com wrote: On 18 January 2012 07:46, Georg Brandl g.bra...@gmx.net wrote: But I am dubious that releases that are obsolete in 6 months and lack 3rd party support will see much production use. Whether people would use the releases is probably something that only they can tell us -- that's why a community survey is mentioned in the PEP. The class of people who we need to consider carefully is those who want to use the latest release, but are limited by the need for other parties to release stuff that works with that release (usually, this means Windows binaries of extensions, or platform vendor packaged releases of modules/packages). Well, do consider, though, that anyone not using third-party C extensions under Windows (either Windows users that are content with pure Python libs, or users of other platforms) won't have that problem. That should be quite a lot of people already. As for vendors, they have their own release management independent of ours already, so this PEP wouldn't change anything for them. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Wed, 18 Jan 2012 11:37:08 +0900 Stephen J. Turnbull step...@xemacs.org wrote: availability of release management volunteers, Dramatic increase here. It may look like RM is not so demanding -- run a few scripts to put out the alphas/betas/releases. But the RM needs to stay on top of breaking news, make decisions. That takes time, interrupts other work, etc. Georg and Barry may answer you here: they are release managers and PEP co-authors. quick availability of new features (and behavioural changes), These are already *available*, just not *tested*. Since testing is the bottleneck on what users consider to be available for me, you cannot decrease the amount of testing (alpha, beta releases) by anywhere near the amount you're increasing frequency, or you're just producing as is snapshots. The point is to *increase* the amount of testing by making features available in stable releases on a more frequent basis. Not decrease it. Alphas and betas never produce much feedback, because people are reluctant to install them for anything else than toying around. Python is not emacs or Firefox, you don't use it in a vacuum and therefore installing non-stable versions is dangerous. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
This won't be a surprise to Antoine or Georg (since I've already expressed the same opinion privately), but I'm -1 on the idea of official releases of the whole shebang every 6 months. We're not Ubuntu, Fedora, Chrome or Firefox with a for-profit company (or large foundation) with multiple paid employees kicking around to really drive the QA process. If we had official support from Red Hat or Canonical promising to devote paid QA and engineering resources to keeping things on track my opinion might be different, but that is highly unlikely. I'm also wholly in agreement with Ezio that using the same versioning scheme for both full releases and interim releases is thoroughly confusing for users (for example, I consider Red Hat's completely separate branding and versioning for Fedora and RHEL a better model for end users than Canonical's more subtle 'Ubuntu' and 'Ubuntu LTS' distinction, and that's been my opinion since long before I started working for RH). My original suggestion to Antoine and Georg for 3.4 was that we simply propose to Larry Hastings (the 3.4 RM) that we spread out the release cycle, releasing the first alpha after ~6 months, the second after about ~12, then rolling into the regular release cycle of a final alpha, some beta releases, one or two release candidates and then the actual release. However, I'm sympathetic to Antoine's point that early alphas aren't likely to be at all interesting to folks that would like a fully supported stdlib update to put into production and no longer think that suggestion makes much sense on its own. Instead, if the proposal involves instituting a PEP 3003 style moratorium (i.e. stdlib changes only) for all interim releases, then we're essentially talking about splitting the versioning of the core language (and the CPython C API) and the standard library. If we're going to discuss that, we may as well go a bit further and just split development of the two out onto separate branches, with the current numbering scheme applying to full language version releases and switching to a date-based versioning scheme for the standard library (i.e. if 3.3 goes out in August as planned, then it would be Python 3.3 with the 12.08 stdlib release). What might such a change mean? 1. For 3.3, the following releases would be made: - 3.2.x is cut from the 3.2 branch (1 rc + 1 release) - 3.3.0 + PyStdlib 12.08 is created from the default branch (1 alpha, 2 betas, 1+ rc, 1 release) - the 3.3 maintenance branch is created - the stdlib development branch is created 2. Once 3.2 goes into security-fix only mode, this would then leave us with 4 active branches: - 2.7 (maintenance) - 3.3 (maintenance) - stdlib (Python 3.3 compatible, PEP 3003 compliant updates) - default (3.4 development) The 2.7 branch would remain a separate head of development, but for 3.x development the update flow would become: Bug fixes: 3.3-stdlib-default Stdlib features: stdlib-default Language changes: default 3. Somewhere around February 2013, we prepare to release Python 3.4a1 and 3.3.1, along with PyStdlib 13.02: - 3.3.1 + PyStdlib 12.08 is cut from the 3.3 branch (1 rc + 1 release) - 3.3.1 + PyStdlib 13.02 comes from the stdlib branch (1 alpha, 1 beta, 1+ rc, 1 release) - 3.4.0a1 comes from the default branch (may include additional stdlib changes) 4. Around August 2013 this process repeats: - 3.3.2 + PyStdlib 12.08 is cut from the 3.3 branch - 3.3.2 + PyStdlib 13.08 comes from the stdlib branch (final 3.3 compatible stdlib release) - 3.4.0a2 comes from the default branch 5. And then in February 2014, we gear up for a new major release: - 3.3.3 is cut from the 3.3 branch and the 3.3 branch enters security fix only mode - 3.4.0 + PyStdlib 14.02 is created from the default branch (1 alpha, 2 betas, 1+ rc, 1 release) - the 3.4 maintenance branch is created and merged into the stdlib branch (alternatively, Feb 2014 could be another interim release of 3.4 alpha and a 3.3 compatible stdlib updated, with 3.4 delayed until August 2014) I believe this approach would get to the core of what the PEP authors want (i.e. more frequent releases of the standard library), while being quite explicit in *avoiding* the concerns associated with more frequent releases of the core language itself. The rate of updates on the language spec, the C API (and ABI), the bytecode format and the AST would remain largely unchanged at 18-24 months. Other key protocols (e.g. default pickle formats) could also be declared ineligible for changes in interim releases. If a critical security problem is found, then additional releases may be cut for the maintenance branch and for the stdlib branch. There's a slight annoyance in having all development filtered through an additional branch, but there's a large advantage in that having a stable core in the stdlib branch makes it more likely we'll be able to use it as a venue for collaboration with the
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Antoine Pitrou writes: Since testing is the bottleneck on what users consider to be available for me, you cannot decrease the amount of testing (alpha, beta releases) by anywhere near the amount you're increasing frequency, or you're just producing as is snapshots. The point is to *increase* the amount of testing by making features available in stable releases on a more frequent basis. Not decrease it. We're talking about different kinds of testing. You're talking about (what old-school commercial software houses meant by beta) testing in a production or production prototype environment. I'd love to see more of that, too! My claim is that I don't expect much uptake if you don't do close to as many of what are called alpha and beta tests on python-dev as are currently done. Alphas and betas never produce much feedback, because people are reluctant to install them for anything else than toying around. Python is not emacs or Firefox, you don't use it in a vacuum and therefore installing non-stable versions is dangerous. Exactly my point, except that the PEP authors seem to think that we can cut back on the number of alpha and beta prereleases and still achieve the stability that such users expect from a Python release. I don't think that's right. I expect that unless quite substantial resources (far more than proportional to 1/frequency) are devoted to each non-LTS release, a large fraction of such users to avoid non-LTS releases the way they avoid betas now. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Le mercredi 18 janvier 2012 à 21:48 +0900, Stephen J. Turnbull a écrit : My claim is that I don't expect much uptake if you don't do close to as many of what are called alpha and beta tests on python-dev as are currently done. You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. I don't know of any users who would bother about that. (you can produce flimsy software with many alphas, too) Alphas and betas never produce much feedback, because people are reluctant to install them for anything else than toying around. Python is not emacs or Firefox, you don't use it in a vacuum and therefore installing non-stable versions is dangerous. Exactly my point, except that the PEP authors seem to think that we can cut back on the number of alpha and beta prereleases and still achieve the stability that such users expect from a Python release. I don't think that's right. Sure, and we think it is :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Antoine Pitrou writes: You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. Surely testing is related to user perceptions of stability. More testing helps reduce bugs in released software, which improves user perception of stability, encouraging them to use the software in production. Less testing, then, will have the opposite effect. But you understand that theory, I'm sure. So what do you mean to say? (you can produce flimsy software with many alphas, too) The problem is the converse: can you produce Python-release-quality software with much less pre-release testing than current feature releases get? Sure, and we think it is [possible to do that] :) Given the relative risk of rejecting PEP 407 and me being wrong (the status quo really isn't all that bad AFAICS), vs. accepting PEP 407 and you being wrong, I don't find a smiley very convincing. In fact, I don't find the PEP itself convincing -- and I'm not the only one. We'll see what Barry and Georg have to say. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit : You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. Surely testing is related to user perceptions of stability. More testing helps reduce bugs in released software, which improves user perception of stability, encouraging them to use the software in production. I have asked a practical question, a theoretical answer isn't exactly what I was waiting for. Sure, and we think it is [possible to do that] :) Given the relative risk of rejecting PEP 407 and me being wrong (the status quo really isn't all that bad AFAICS), vs. accepting PEP 407 and you being wrong, I don't find a smiley very convincing. I don't care to convince *you*, since you are not involved in Python development and release management (you haven't ever been a contributor AFAIK). Unless you produce practical arguments, saying I don't think you can do it is plain FUD and certainly not worth answering to. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Wed, Jan 18, 2012 at 09:26:19PM +1000, Nick Coghlan wrote: My original suggestion to Antoine and Georg for 3.4 was that we simply propose to Larry Hastings (the 3.4 RM) that we spread out the release cycle, releasing the first alpha after ~6 months, the second after about ~12, then rolling into the regular release cycle of a final alpha, some beta releases, one or two release candidates and then the actual release. However, I'm sympathetic to Antoine's point that early alphas aren't likely to be at all interesting to folks that would like a fully supported stdlib update to put into production and no longer think that suggestion makes much sense on its own. This looks like a 'good bridge' of suggestion between rapid releases and stable releases. What would be purpose of alpha release. Would we encourage people to use it or test it? Which the rapid relase cycle, the encouragement is to use rather than test. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Tuesday, January 17, 2012, Antoine Pitrou solip...@pitrou.net wrote: We would like to propose the following PEP to change (C)Python's release cycle. Discussion is welcome, especially from people involved in the release process, and maintainers from third-party distributions of Python. As a Gentoo packager, this would mean much more work for us, unless all the non-LTS releases promised to be backwards compatible. I.e. the hard part for us is managing all the incompatibilities in other packages, compatibility with Python. As a user of Python, I would rather dislike the change from 18 to 24 months for LTS release cycles. And the limiting factor for my use of Python features is largely old Python versions still in use, not the availability of newer features in the newest Python. So I'm much more interested in finding ways of improving 2.7/3.2 uptake than adding more feature releases. I also think that it would be sensible to wait with something like this process change until the 3.x adoption curve is much further along. Cheers, Dirkjan Regards Antoine. PEP: 407 Title: New release cycle and introducing long-term support versions Version: $Revision$ Last-Modified: $Date$ Author: Antoine Pitrou solip...@pitrou.net, Georg Brandl ge...@python.org, Barry Warsaw ba...@python.org Status: Draft Type: Process Content-Type: text/x-rst Created: 2012-01-12 Post-History: Resolution: TBD Abstract Finding a release cycle for an open-source project is a delicate exercise in managing mutually contradicting constraints: developer manpower, availability of release management volunteers, ease of maintenance for users and third-party packagers, quick availability of new features (and behavioural changes), availability of bug fixes without pulling in new features or behavioural changes. The current release cycle errs on the conservative side. It is adequate for people who value stability over reactivity. This PEP is an attempt to keep the stability that has become a Python trademark, while offering a more fluid release of features, by introducing the notion of long-term support versions. Scope = This PEP doesn't try to change the maintenance period or release scheme for the 2.7 branch. Only 3.x versions are considered. Proposal Under the proposed scheme, there would be two kinds of feature versions (sometimes dubbed minor versions, for example 3.2 or 3.3): normal feature versions and long-term support (LTS) versions. Normal feature versions would get either zero or at most one bugfix release; the latter only if needed to fix critical issues. Security fix handling for these branches needs to be decided. LTS versions would get regular bugfix releases until the next LTS version is out. They then would go into security fixes mode, up to a termination date at the release manager's discretion. Periodicity --- A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. With these figures, a new LTS version would be out every 24 months, and remain supported until the next LTS version 24 months later. This is mildly similar to today's 18 months bugfix cycle for every feature version. Pre-release versions More frequent feature releases imply a smaller number of disruptive changes per release. Therefore, the number of pre-release builds (alphas and betas) can be brought down considerably. Two alpha builds and a single beta build would probably be enough in the regular case. The number of release candidates depends, as usual, on the number of last-minute fixes before final release. Effects === Effect on development cycle --- More feature releases might mean more stress on the development and release management teams. This is quantitatively alleviated by the smaller number of pre-release versions; and qualitatively by the lesser amount of disruptive changes (meaning less potential for breakage). The shorter feature freeze period (after the first beta build until the final release) is easier to accept. The rush for adding features just before feature freeze should also be much smaller. Effect on bugfix cycle -- The effect on fixing bugs should be minimal with the proposed figures. The same number of branches would be simultaneously open for regular maintenance (two until 2.x is terminated, then one). Effect on workflow -- The workflow for new features would be the same: developers would only commit them on the ``default`` branch. The workflow for bug fixes would be slightly updated: developers would commit bug fixes to the current LTS branch (for example ``3.3``) and then merge them into ``default``. ___ Python-Dev
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Hello Dirkjan, On Wed, 18 Jan 2012 18:32:22 +0100 Dirkjan Ochtman dirk...@ochtman.nl wrote: On Tuesday, January 17, 2012, Antoine Pitrou solip...@pitrou.net wrote: We would like to propose the following PEP to change (C)Python's release cycle. Discussion is welcome, especially from people involved in the release process, and maintainers from third-party distributions of Python. As a Gentoo packager, this would mean much more work for us, unless all the non-LTS releases promised to be backwards compatible. I.e. the hard part for us is managing all the incompatibilities in other packages, compatibility with Python. It might need to be spelt clearly in the PEP, but one of my assumptions is that packagers choose on what release series they want to synchronize. So packagers can synchronize on the LTS releases if it's more practical for them, or if it maps better to their own release model (e.g. Debian). Do you think that's a valid answer to Gentoo's concerns? So I'm much more interested in finding ways of improving 2.7/3.2 uptake than adding more feature releases. That would be nice as well, but I think it's orthogonal to the PEP. Besides, I'm afraid there's not much we (python-dev) can do about it. Some vendors (Debian, Redhat) will always lag behind the bleeding-edge feature releases. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 18.01.2012 16:25, schrieb Stephen J. Turnbull: Antoine Pitrou writes: You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. Surely testing is related to user perceptions of stability. More testing helps reduce bugs in released software, which improves user perception of stability, encouraging them to use the software in production. Less testing, then, will have the opposite effect. But you understand that theory, I'm sure. So what do you mean to say? (you can produce flimsy software with many alphas, too) The problem is the converse: can you produce Python-release-quality software with much less pre-release testing than current feature releases get? Sure, and we think it is [possible to do that] :) Given the relative risk of rejecting PEP 407 and me being wrong (the status quo really isn't all that bad AFAICS), vs. accepting PEP 407 and you being wrong, I don't find a smiley very convincing. The status quo really isn't all that bad applies to any PEP. Also, compared to most PEPs, it is quite easy to revert to the previous state of things if they don't work out as wanted. In fact, I don't find the PEP itself convincing -- and I'm not the only one. That is noted. And I think Antoine was a little harsh earlier; of course we also need to convince users that the new cycle is advantageous and not detrimental. We'll see what Barry and Georg have to say. Two things: a) The release manager's job is not as bad as you might believe. We have an incredibly helpful and active core of developers which means that the RM job is more or less reduced to pronouncing on changes during the rc phase, and actually producing the releases. b) I did not have the impression (maybe someone can underline that with tracker stats?) that there were a lot more bug reports than usual during the alpha and early beta stages of Python 3.2. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Antoine Pitrou wrote: Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit : You claim people won't use stable releases because of not enough alphas? That sounds completely unrelated. Surely testing is related to user perceptions of stability. More testing helps reduce bugs in released software, which improves user perception of stability, encouraging them to use the software in production. I have asked a practical question, a theoretical answer isn't exactly what I was waiting for. [...] I don't care to convince *you*, since you are not involved in Python development and release management (you haven't ever been a contributor AFAIK). Unless you produce practical arguments, saying I don't think you can do it is plain FUD and certainly not worth answering to. Pardon me, but people like Stephen Turnbull are *users* of Python, exactly the sort of people you DO have to convince that moving to an accelerated or more complex release process will result in a better product. The risk is that you will lose users, or fragment the user base even more than it is now with 2.x vs 3.x. Quite frankly, I like the simplicity and speed of the current release cycle. All this talk about separate LTS releases and parallel language releases and library releases makes my head spin. I fear the day that people asking questions on the tutor or python-list mailing lists will have to say (e.g.) I'm using Python 3.4.1 and standard library 1.2.7 in order to specify the version they're using. I fear change, because the current system works well and for every way to make it better there are a thousand ways to make it worse. Dismissing fears like this as FUD doesn't do anyone any favours. One on-going complaint is that Python-Dev doesn't have the manpower or time to do everything that needs to be done. Bugs languish for months or years because nobody has the time to look at it. Will going to a more rapid release cycle give people more time, or just increase their workload? You're hoping that a more rapid release cycle will attract more developers, and there is a chance that you could be right; but a more rapid release cycle WILL increase the total work load. So you're betting that this change will attract enough new developers that the work load per person will decrease even as the total work load increases. I don't think that's a safe bet. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl g.bra...@gmx.net wrote: The main reason is changes in the library. We have been getting complaints about the standard library bitrotting for years now, and one of the main reasons it's so hard to a) get decent code into the stdlib and b) keep it maintained is that the release cycles are so long. It's a tough thing for contributors to accept that the feature you've just implemented will only be in a stable release in 16 months. If the stdlib does not get more reactive, it might just as well be cropped down to a bare core, because 3rd-party libraries do everything as well and do it before we do. But you're right that if Python came without batteries, the current release cycle would be fine. I think this is the real issue here. The batteries in Python are so important because: 1) The stability and quality of 3rd party libraries is not guaranteed. 2) The mechanism used to obtain 3rd party libraries, is not popular or considered reliable. Much of the bitrot is that standard library modules have been deprecated by third party ones that are of a much higher functionality. Rather than importing these libraries, it needs to be trivial to obtain them. Putting some of these higher quality 3rd party modules into lock step with Python is an unpopular move, and hampers their future growth. From the top of my head, libraries such as LXML, argparse, and requests are such popular libraries that shouldn't be baked in. In the long term, it would be nice to see these kinds of libraries dropped from the standard installation, and made available through the new distribute package systems etc. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Georg Brandl writes: The status quo really isn't all that bad applies to any PEP. Also, compared to most PEPs, it is quite easy to revert to the previous state of things if they don't work out as wanted. That depends on how doesn't work out plays out. If meeting the schedule *and* producing a good release regularly is just more work than expected, of course you're right. If you stick to the schedule with insufficient resources, and lack of testing produces a really bad release (or worse, a couple of sorta bad releases in succession), reverting Python's reputation for stability is going to be non-trivial. a) The release manager's job is not as bad as you might believe. We have an incredibly helpful and active core of developers which means that the RM job is more or less reduced to pronouncing on changes during the rc phase, and actually producing the releases. I've done release management and I've been watching Python do release management since PEP 263; I'm well aware that Python has a truly excellent process in place, and I regularly recommend studying to friends interested in improving their own projects' processes. But I've also (twice) been involved (as RM) in a major revision of RM procedures, and both times it was a lot more work than anybody expected. Finally, the whole point of this exercise is to integrate a lot more stdlib changes (including whole packages) than in the past on a much shorter timeline, and to do it repeatedly. Every six months still sounds like a long time if you are a leaf project still working on your changes on your own schedule and chafing at the bit waiting to get them in to the core project's releases, but it's actually quite short for the RM. I'm not against this change (especially since, as Antoine so graciously pointed out, I'm not going to be actually doing the work in the foreseeable future), but I do advise that the effort required seemed to be dramatically underestimated. b) I did not have the impression (maybe someone can underline that with tracker stats?) that there were a lot more bug reports than usual during the alpha and early beta stages of Python 3.2. Yeah, but the question for Python's stability reputation is were there more than zero? Every bug that gets through is a risk. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Steven D'Aprano writes: Pardon me, but people like Stephen Turnbull are *users* of Python, exactly the sort of people you DO have to convince that moving to an accelerated or more complex release process will result in a better product. Well, to be fair, Antoine is right in excluding me from the user base he's trying to attract (as I understand it). I do not maintain products or systems that depend on Python working 99.9% of the time, and in fact in many of my personal projects I use trunk. One of the problems with this kind of discussion is that the targets of the new procedures are not clear in everybody's mind, but all of us tend to use generic terms like users when we mean to discuss benefits or costs to a specific class of users. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Tue, Jan 17, 2012 at 1:34 PM, Antoine Pitrou solip...@pitrou.net wrote: Under the proposed scheme, there would be two kinds of feature versions (sometimes dubbed minor versions, for example 3.2 or 3.3): normal feature versions and long-term support (LTS) versions. ... A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. It sounds like every six months we would get a new feature version, with every fourth one an LTS release. That sounds great, but, unless I've misunderstood, there has been a strong desire to keep that number to one digit. It doesn't matter to me all that much. However, if there is such a limit, implied or explicit, it should be mentioned and factor into the PEP. That aside, +1. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
If minor/feature releases are introducing breaking changes perhaps it's time to adopt accelerated major versioning schedule. For instance there are breaking ABI changes between 3.0/3.1, and 3.2, and while acceptable for the early adoption state of Python 3, such changes should normally be reserved for major versions. If every 4th or so feature release is sufficiently different to be worth of an LTS, consider this a major release albeit with smaller beading changes than Python 3. Aside from this, given the radical features of 3.3, and the upcoming Ubuntu 12.04 LTS, I would recommend adopting 2.7 and 3.2 as the first LTSs, to be reviewed 2 years hence should this go ahead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Hello, On Wed, 18 Jan 2012 10:04:19 +1100 Matt Joiner anacro...@gmail.com wrote: If minor/feature releases are introducing breaking changes perhaps it's time to adopt accelerated major versioning schedule. The PEP doesn't propose to accelerate compatibility breakage. So I don't think a change in numbering is required. For instance there are breaking ABI changes between 3.0/3.1, and 3.2, and while acceptable for the early adoption state of Python 3, such changes should normally be reserved for major versions. Which breaking ABI changes are you thinking about? Python doesn't guarantee any A*B*I (as opposed to API), unless you use Py_LIMITED_API which was introduced in 3.2. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 1/17/2012 3:34 PM, Antoine Pitrou wrote: Hello, We would like to propose the following PEP to change (C)Python's release cycle. Discussion is welcome, especially from people involved in the release process, and maintainers from third-party distributions of Python. Regards Antoine. PEP: 407 Title: New release cycle and introducing long-term support version To me, as I understand the proposal, the title is wrong. Our current feather releases already are long-term support versions. They get bugfix releases at close to 6 month intervals for 1 1/2 -2 years and security fixes for 3 years. The only change here is that you propose, for instance, a fixed 6-month interval and 2 year period. As I read this, you propose to introduce a new short-term (interim, preview) feature release along with each bugfix release. Each would have all the bugfixes plus a preview of the new features expected to be in the next long-term release. (I know, this is not exactly how you spun it.) There has been discussion on python-ideas about whether new features are or can be considered experimental, or whether there should be an 'experimental' package. An argument against is that long-term production releases should not have experimental features that might go away or have their apis changed. If the short-term, non-production, interim feature releases were called preview releases, then some or all of the new features could be labelled experimental and subject to change. It might actually be good to have major new features tested in at least one preview release before being frozen. Maybe then more of the initial bugs would be found and repaired *before* their initial appearance in a long-term release. (All of this is not to say that experimental features should be casually changed or reverted without good reason.) One problem, at least on Windows, is that short-term releases would almost never have compiled binaries for 3rd-party libraries. It already takes awhile for them to appear for the current long-term releases. On the other hand, library authors might be more inclined to test new features, a few at a time, if part of tested preview releases, than if just in the repository. So the result *might* be quicker library updates after each long-term release. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Tue, 17 Jan 2012 18:29:11 -0500 Terry Reedy tjre...@udel.edu wrote: To me, as I understand the proposal, the title is wrong. Our current feather releases already are long-term support versions. They get bugfix releases at close to 6 month intervals for 1 1/2 -2 years and security fixes for 3 years. The only change here is that you propose, for instance, a fixed 6-month interval and 2 year period. As I read this, you propose to introduce a new short-term (interim, preview) feature release along with each bugfix release. Each would have all the bugfixes plus a preview of the new features expected to be in the next long-term release. (I know, this is not exactly how you spun it.) Well, spinning is important here. We are not proposing any preview releases. These would have the same issue as alphas or betas: nobody wants to install them where they could disrupt working applications and libraries. What we are proposing are first-class releases that are as robust as any other (and usable in production). It's really about making feature releases more frequent, not making previews available during development. I agree long-term could be misleading as their support duration is not significantly longer than current feature releases. I chose this term because it is quite well-known and well-understood, but we could pick something else (extended support, 2-year support, etc.). There has been discussion on python-ideas about whether new features are or can be considered experimental, or whether there should be an 'experimental' package. An argument against is that long-term production releases should not have experimental features that might go away or have their apis changed. That's orthogonal to this PEP. (that said, more frequent feature releases are also a benefit for the __preview__ proposal, since we could be more reactive changing APIs in that namespace) One problem, at least on Windows, is that short-term releases would almost never have compiled binaries for 3rd-party libraries. That's a good point, although Py_LIMITED_API will hopefully make things better in the middle term. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Hi, On 17/01/2012 22.34, Antoine Pitrou wrote: [...] Proposal Under the proposed scheme, there would be two kinds of feature versions (sometimes dubbed minor versions, for example 3.2 or 3.3): normal feature versions and long-term support (LTS) versions. Normal feature versions would get either zero or at most one bugfix release; the latter only if needed to fix critical issues. Security fix handling for these branches needs to be decided. If non-LTS releases won't get bug fixes, a bug that is fixed in 3.3.x might not be fixed in 3.4, unless the bug fixes releases are synchronized with the new feature releases (see below). LTS versions would get regular bugfix releases until the next LTS version is out. They then would go into security fixes mode, up to a termination date at the release manager's discretion. Periodicity --- A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. If LTS bug fixes releases and feature releases are synchronized, we will have something like: 3.3 3.3.1 / 3.4 3.3.2 / 3.5 3.3.3 / 3.6 3.7 3.7.1 / 3.8 ... so every new feature release will have all the bug fixes of the current LTS release, plus new features. With this scheme we will soon run out of 1-digit numbers though. Currently we already have a 3.x release every ~18 months, so if we keep doing that (just every 24 months instead of 18) and introduce the feature releases in between under a different versioning scheme, we might avoid the problem. This means: 3.1 ... 18 months, N bug fix releases... 3.2 ... 18 months, N bug fix releases ... 3.3 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.4 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.5 LTS In this way we solve the numbering problem and keep a familiar scheme (all the 3.x will be LTS and will be released as the same pace as before, no need to mark some 3.x as LTS). OTOH this will make the feature releases less noticeable and people might just ignore them and stick with the LTS releases. Also we would need to define a versioning convention for the feature releases. [...] Effect on bugfix cycle -- The effect on fixing bugs should be minimal with the proposed figures. The same number of branches would be simultaneously open for regular maintenance (two until 2.x is terminated, then one). Wouldn't it still be two? Bug fixes will go to the last LTS and on default, features only on default. Effect on workflow -- The workflow for new features would be the same: developers would only commit them on the ``default`` branch. The workflow for bug fixes would be slightly updated: developers would commit bug fixes to the current LTS branch (for example ``3.3``) and then merge them into ``default``. So here the difference is that instead of committing on the previous release (what currently is 3.2), we commit it to the previous LTS release, ignoring the ones between that and default. If some critical fixes are needed to a non-LTS version, they can be grafted from the current LTS branch to the non-LTS branch, just like fixes are ported from 3.x to 2.7 today. Effect on the community --- People who value stability can just synchronize on the LTS releases which, with the proposed figures, would give a similar support cycle (both in duration and in stability). That's why I proposed to keep the same versioning scheme for these releases, and have a different numbering for the feature releases. [...] Discussion == These are open issues that should be worked out during discussion: * Decide on X (months between feature releases) and N (feature releases per LTS release) as defined above. This doesn't necessarily have to be fixed, especially if we don't change the versioning scheme (so we don't need to know that we have a LTS release every N releases). * For given values of X and N, is the no-bugfix-releases policy for non-LTS versions feasible? If LTS bug fix releases and feature releases are synchronized it should be feasible. * Restrict new syntax and similar changes (i.e. everything that was prohibited by PEP 3003) to LTS versions? (I was reading this the other way around, maybe rephrase it to Allow new syntax and similar changes only in LTS versions) * What is the effect on packagers such as Linux distributions? * What is the effect on PyPy/Jython/IronPython? Can they just skip the feature releases and focus on the LTS ones? * How will release version numbers or other identifying and marketing material make it clear to users which versions are normal feature releases and which are LTS releases? How do we manage user expectations? This is not an issue with the scheme I proposed. A community poll or survey to collect opinions from the greater Python
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti ezio.melo...@gmail.com wrote: * What is the effect on PyPy/Jython/IronPython? Can they just skip the feature releases and focus on the LTS ones? At least for IronPython it's unlikely we'd be able track the feature releases. We're still trying to catch up as it is. Honestly, I don't see the advantages of this. Are there really enough new features planned that Python needs a full release more than every 18 months? - Jeff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 1/17/2012 6:42 PM, Antoine Pitrou wrote: On Tue, 17 Jan 2012 18:29:11 -0500 Terry Reedytjre...@udel.edu wrote: To me, as I understand the proposal, the title is wrong. Our current feather releases already are long-term support versions. They get bugfix releases at close to 6 month intervals for 1 1/2 -2 years and security fixes for 3 years. The only change here is that you propose, for instance, a fixed 6-month interval and 2 year period. As I read this, you propose to introduce a new short-term (interim, preview) feature release along with each bugfix release. Each would have all the bugfixes plus a preview of the new features expected to be in the next long-term release. (I know, this is not exactly how you spun it.) The main point of my comment is that the new thing you are introducing is not long-term supported versions but short term unsupported versions. Well, spinning is important here. We are not proposing any preview releases. These would have the same issue as alphas or betas: nobody I said nothing about quality. We aim to keep default in near-release condition and seem to be getting better. The new unicode is still getting polished a bit, it seems, after 3 months, but that is fairly unusual. wants to install them where they could disrupt working applications and libraries. What we are proposing are first-class releases that are as robust as any other (and usable in production). But I am dubious that releases that are obsolete in 6 months and lack 3rd party support will see much production use. It's really about making feature releases more frequent, not making previews available during development. Given the difficulty of making a complete windows build, it would be nice to have one made available every 6 months, regardless of how it is labeled. I believe that some people will see and use good-for-6-months releases as previews of the new features that will be in the 'real', normal, bug-fix supported, long-term releases. Every release is a snapshot of a continuous process, with some extra effort made to tie up some (but not all) of the loose ends. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 18.01.2012 05:32, schrieb Terry Reedy: On 1/17/2012 6:42 PM, Antoine Pitrou wrote: On Tue, 17 Jan 2012 18:29:11 -0500 Terry Reedytjre...@udel.edu wrote: To me, as I understand the proposal, the title is wrong. Our current feather releases already are long-term support versions. They get bugfix releases at close to 6 month intervals for 1 1/2 -2 years and security fixes for 3 years. The only change here is that you propose, for instance, a fixed 6-month interval and 2 year period. As I read this, you propose to introduce a new short-term (interim, preview) feature release along with each bugfix release. Each would have all the bugfixes plus a preview of the new features expected to be in the next long-term release. (I know, this is not exactly how you spun it.) The main point of my comment is that the new thing you are introducing is not long-term supported versions but short term unsupported versions. That is really a matter of perspective. For the proposed cycle, there would be more regular version than LTS versions, so they are the exception and get the special name. (And at the same time, the name is already established and people probably grasp instantly what it means.) Well, spinning is important here. We are not proposing any preview releases. These would have the same issue as alphas or betas: nobody I said nothing about quality. We aim to keep default in near-release condition and seem to be getting better. The new unicode is still getting polished a bit, it seems, after 3 months, but that is fairly unusual. wants to install them where they could disrupt working applications and libraries. What we are proposing are first-class releases that are as robust as any other (and usable in production). But I am dubious that releases that are obsolete in 6 months and lack 3rd party support will see much production use. Whether people would use the releases is probably something that only they can tell us -- that's why a community survey is mentioned in the PEP. Not sure what you mean by lacking 3rd party support. It's really about making feature releases more frequent, not making previews available during development. Given the difficulty of making a complete windows build, it would be nice to have one made available every 6 months, regardless of how it is labeled. I believe that some people will see and use good-for-6-months releases as previews of the new features that will be in the 'real', normal, bug-fix supported, long-term releases. Maybe they will. That's another thing that is made clear in the PEP: for one group of people (those preferring stability over long time), nothing much changes, except that the release period is a little longer, and there are these previews as you call them. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 18 January 2012 04:32, Terry Reedy tjre...@udel.edu wrote: It's really about making feature releases more frequent, not making previews available during development. Given the difficulty of making a complete windows build, it would be nice to have one made available every 6 months, regardless of how it is labeled. I believe that some people will see and use good-for-6-months releases as previews of the new features that will be in the 'real', normal, bug-fix supported, long-term releases. I'd love to see 6-monthly releases, including Windows binaries, and binary builds of all packages that needed a compiler to build. Oh, and a pony every LTS release :-) Seriously, this proposal doesn't really acknowledge the amount of work by other people that would be needed for a 6-month release to be *usable* in normal cases (by Windows users, at least). It's usually some months after a release on the current schedule that Windows binaries have appeared for everything I use regularly. I could easily imagine 3rd-party developers tending to only focus on LTS releases, making the release cycle effectively *slower* for me, rather than faster. Paul PS Things that might help improve this: (1) PY_LIMITED_API, and (2) support in packaging for binary releases, including a way to force installation of a binary release on the wrong version (so that developers don't have to repackage and publish identical binaries every 6 months). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 18.01.2012 01:24, schrieb Jeff Hardy: On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti ezio.melo...@gmail.com wrote: * What is the effect on PyPy/Jython/IronPython? Can they just skip the feature releases and focus on the LTS ones? At least for IronPython it's unlikely we'd be able track the feature releases. We're still trying to catch up as it is. Honestly, I don't see the advantages of this. Are there really enough new features planned that Python needs a full release more than every 18 months? Yes, we think so. (What is a non-full release, by the way?) The main reason is changes in the library. We have been getting complaints about the standard library bitrotting for years now, and one of the main reasons it's so hard to a) get decent code into the stdlib and b) keep it maintained is that the release cycles are so long. It's a tough thing for contributors to accept that the feature you've just implemented will only be in a stable release in 16 months. If the stdlib does not get more reactive, it might just as well be cropped down to a bare core, because 3rd-party libraries do everything as well and do it before we do. But you're right that if Python came without batteries, the current release cycle would be fine. (Another, more far-reaching proposal, has been to move the stdlib out of the cpython repo and share a new repo with Jython/IronPython/PyPy. It could then also be released separately from the core. But this is much more work than the current proposal.) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
On 18 January 2012 07:46, Georg Brandl g.bra...@gmx.net wrote: But I am dubious that releases that are obsolete in 6 months and lack 3rd party support will see much production use. Whether people would use the releases is probably something that only they can tell us -- that's why a community survey is mentioned in the PEP. The class of people who we need to consider carefully is those who want to use the latest release, but are limited by the need for other parties to release stuff that works with that release (usually, this means Windows binaries of extensions, or platform vendor packaged releases of modules/packages). For them, if the other parties focus on LTS releases (as is possible, certainly) the release cycle became slower, going from 18 months to 24. Not sure what you mean by lacking 3rd party support. I take it as meaning that the people who release Windows binaries on PyPI, and vendors who package up PyPI distributions in their own distribution format. Lacking support in the sense that these people might well decide that a 6 month cycle is too fast (too much work) and explicitly decide to focus only on LTS releases. Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions
Am 18.01.2012 00:50, schrieb Ezio Melotti: Hi, On 17/01/2012 22.34, Antoine Pitrou wrote: [...] Proposal Under the proposed scheme, there would be two kinds of feature versions (sometimes dubbed minor versions, for example 3.2 or 3.3): normal feature versions and long-term support (LTS) versions. Normal feature versions would get either zero or at most one bugfix release; the latter only if needed to fix critical issues. Security fix handling for these branches needs to be decided. If non-LTS releases won't get bug fixes, a bug that is fixed in 3.3.x might not be fixed in 3.4, unless the bug fixes releases are synchronized with the new feature releases (see below). That's already the case today. 3.2.5 might be released before 3.3.1 and therefore include bugfixes that 3.3.0 doesn't. True, there will be a 3.3.1 afterwards that does include it, but in the new case, there will be a new feature release instead. LTS versions would get regular bugfix releases until the next LTS version is out. They then would go into security fixes mode, up to a termination date at the release manager's discretion. Periodicity --- A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. If LTS bug fixes releases and feature releases are synchronized, we will have something like: 3.3 3.3.1 / 3.4 3.3.2 / 3.5 3.3.3 / 3.6 3.7 3.7.1 / 3.8 ... so every new feature release will have all the bug fixes of the current LTS release, plus new features. With this scheme we will soon run out of 1-digit numbers though. Currently we already have a 3.x release every ~18 months, so if we keep doing that (just every 24 months instead of 18) and introduce the feature releases in between under a different versioning scheme, we might avoid the problem. This means: 3.1 ... 18 months, N bug fix releases... 3.2 ... 18 months, N bug fix releases ... 3.3 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.4 LTS ... 24 months, 3 bug fix releases, 3 feature releases ... 3.5 LTS In this way we solve the numbering problem and keep a familiar scheme (all the 3.x will be LTS and will be released as the same pace as before, no need to mark some 3.x as LTS). OTOH this will make the feature releases less noticeable and people might just ignore them and stick with the LTS releases. Also we would need to define a versioning convention for the feature releases. Let's see how Guido feels about 3.10 first. [...] Effect on bugfix cycle -- The effect on fixing bugs should be minimal with the proposed figures. The same number of branches would be simultaneously open for regular maintenance (two until 2.x is terminated, then one). Wouldn't it still be two? Bug fixes will go to the last LTS and on default, features only on default. Maintenance excludes the feature development branch here. Will clarify. Effect on workflow -- The workflow for new features would be the same: developers would only commit them on the ``default`` branch. The workflow for bug fixes would be slightly updated: developers would commit bug fixes to the current LTS branch (for example ``3.3``) and then merge them into ``default``. So here the difference is that instead of committing on the previous release (what currently is 3.2), we commit it to the previous LTS release, ignoring the ones between that and default. Yes. If some critical fixes are needed to a non-LTS version, they can be grafted from the current LTS branch to the non-LTS branch, just like fixes are ported from 3.x to 2.7 today. Effect on the community --- People who value stability can just synchronize on the LTS releases which, with the proposed figures, would give a similar support cycle (both in duration and in stability). That's why I proposed to keep the same versioning scheme for these releases, and have a different numbering for the feature releases. [...] Discussion == These are open issues that should be worked out during discussion: * Decide on X (months between feature releases) and N (feature releases per LTS release) as defined above. This doesn't necessarily have to be fixed, especially if we don't change the versioning scheme (so we don't need to know that we have a LTS release every N releases). For these relatively short times (X = 6 months), I feel it is important to fix the time spans to have predictability for our developers. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
