[Python-Dev] rationale for the no-new-features approach (original) (raw)
Anthony Baxter anthony at interlink.com.au
Wed Mar 9 13:17:06 CET 2005
- Previous message: [Python-Dev] BRANCH FREEZE for 2.4.1rc1, 0000 UTC, 2005-03-10
- Next message: [Python-Dev] rationale for the no-new-features approach
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
So it's only fair that I write down my rationale for why I'm being anal about the no-new-features approach. Comments are more than welcome - ideally, after discussion, I'll put some more words in the bugfix PEP.
Goal 1: When we cut a bugfix release, people will upgrade to it.
- This helps the users (they have bugs fixed)
- This helps us (python-dev) because people won't be logging bugs against already-fixed-bugs.
- This makes us (Python) look good, because people using Python have the most bug-free experience possible.
Goal 2: Packagers of Python will package up releases of Python that are as close to the "official" release as possible.
- This, to me, is a huge win. If we don't have to worry about whether someone is running 2.4.1, or DistroFoo's version of 2.4.1 with a couple of backported fixes from 2.4.2, or some other horrible frankenstein's monster of a release, it makes our lives much easier. (This is also why I've been on a bit of a stomping exercise to attempt to get distros that broke Python into pieces to stop doing this (notably, Debian/Ubuntu's distutils- in-python-devel pain))
- And yes, we're always going to have the problem of some distros stuck on old Python releases (Redhat -> Python 1.5.2, Debian stable -> Python 2.1, &c) but we can hopefully encourage them to at least roll out the latest bugfix version of whatever version they're stuck on.
Goal 3: Good PR.
- I've read a disturbing amount of words about other languages (coughJavacough) that have no sanity about minor and major releases. This seems to piss people off a great deal. One of Python's selling points is that we're very cautious and a suitable choice for grownups to use in business.
- This is good for us (Python community) because it makes it less likely we'll be stuck in a job where we're forced to code Perl, or C++, or Java, or some other horrible fate. It also boosts the size of the community, meaning that there will be more volunteers to work on Python (hurrah!)
Goal 4: Try and prevent something like try: True, False except NameError: True, False = 1, 0 from ever ever happening again.
- This, I hope, needs no further explanation
Anthony
-- Anthony Baxter <anthony at interlink.com.au> It's never too late to have a happy childhood.
- Previous message: [Python-Dev] BRANCH FREEZE for 2.4.1rc1, 0000 UTC, 2005-03-10
- Next message: [Python-Dev] rationale for the no-new-features approach
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]