On Wednesday 09 March 2005 23:53, Michael Hudson wrote: > No no no! The point of what Anthony is saying, as I read it,
Your reading of my message is correct. > is that > experience suggests it is exactly this sort of change that should be > avoided. Consider the case of Mac OS X 10.2 which came with Python > 2.2.0: this was pretty broken anyway because of some apple snafus but > it was made even more useless by the fact that people out in the wild > were writing code for 2.2.1 and using True/False/bool. Going from > 2.x.y to 2.x.y+1 shouldn't break anything, going from 2.x.y+1 to 2.x.y > shouldn't break anything that doesn't whack into a bug in 2.x.y -- and > "not having bool" isn't a bug in this sense. This is exactly right, and, assuming people are in agreement, I plan to add text to this effect to PEP 6. One of the slightly negative side effects of Python's growth is that a lot of people depend on it now, and I feel it's in everyone's interests to try and make the best releases I can. We now do more regular bugfix releases - once every 6 months is the goal. Ideally, people shouldn't be _forced_ to upgrade (although obviously I'd prefer if they did <wink>). Assuming that none of the bugs fixed are actually biting you, you should be able to stick with that version of 2.4.0 that's rolled out across hundreds of machines, and not have to worry that someone's writing code against some 2.4.2-specific features. Or, to put it more concisely -- if we allow new features (however minor) in bugfix releases, we're effectively shipping a "new" Python release every 6 months. This is insane. I want to have my cake and eat it too - I want the bugs fixed, but I don't want to have to mess about with worrying about new features each time I need to roll out a new release (in my job). [Disclaimer: It should be obvious here that I'm speaking for myself, and in doing so, I'm wearing a number of different hats - while I'm currently the guy who does the cvs-tag-and-release, I'm also an author of a whole pile of Python software, some open source, some closed (for work). In addition, I need to think about deployment and rollout strategies for new code and new systems in my job. I'm trying to optimise the release process to suit all these hats, and at the same time thinking about what I've been told by other people (distro vendors, people running _very_ large sets of machines with Python software)] In an attempt to stir up some discussion - if you have a reason _for_ allowing new features in a minor release, suggest it! I'm genuinely interested in having this discussion and working out the best solution... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. _______________________________________________ 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
