[Python-Dev] Re: No new features
anthony at interlink.com.au
Wed Mar 9 16:07:48 CET 2005
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 Baxter <anthony at interlink.com.au>
It's never too late to have a happy childhood.
More information about the Python-Dev