> On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote: >> If we intend for 3.0 to be a 'beta release', or to weaken the 'no >> features in micro releases' rule, then fine; but we have to be *really >> clear about it*. Are we? (The 3.0 release page calls it >> production-ready.)
On Thu, Jan 29, 2009 at 8:59 AM, Barry Warsaw <ba...@python.org> wrote: > I think it sets bad precedence to downgrade our confidence in the release. > Again, my position is that it's better to stick to the same development > processes we've always used, fix the most egregious problems in 3.0.1 with > no API changes, but spend most of our energy on a 3.1 release in 6 months. I'd like to find a middle ground. We can all agree that the users of 3.0 are a small minority compared to the 2.x users. Therefore I think we can bend the rules more than we have done for the recent 2.x releases. Those rules weren't always there (anyone remember the addition of bool, True and False to 2.2.1?). The rules were introduced for the benefit of our most conservative users -- people who introduce Python in an enterprise and don't want to find that they are forced to upgrade in six months. Frankly, I don't really believe the users for whom those rules were created are using 3.0 yet. Instead, I expect there to be two types of users: people in the educational business who don't have a lot of bridges to burn and are eager to use the new features; and developers of serious Python software (e.g. Twisted) who are trying to figure out how to port their code to 3.0. The first group isn't affected by the changes we're considering here (e.g. removing cmp or some obscure functions from the operator module). The latter group *may* be affected, simply because they may have some pre-3.0 code using old features that (by accident) still works under 3.0. On the one hand I understand that those folks want a stable target. On the other hand I think they would prefer to find out sooner rather than later they're using stuff they shouldn't be using any more. It's a delicate balance for sure, and I certainly don't want to open the floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I really don't believe that the strictest interpretation of "no new features" will benefit us for 3.0.1. Perhaps we should decide when to go back to a more strict interpretation of the rules based on the uptake of Python 3 compared to Python 2. I don't believe that we risk influencing that uptake by bending the rules; the uptake will depend on the availability of ported 3rd party packages and some performance gains. (I don't know enough about the C reimplementation of io.py to tell whether it could be folded into 3.0 or will have to wait for 3.1.) Finally, to those who claim that 2.6 is a mess because multiprocessing wasn't perfectly stable at introduction: that's never been the standard we've used for totally *new* features. It's always been okay to add slightly immature features at a major release, as long as (a) they don't break anything else, and (b) we can fix things in the next release while maintaining backward compatibility. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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