[Python-Dev] Re: Bug fix releases

Tim Peters tim.one@home.com
Sun, 4 Mar 2001 01:00:44 -0500


[Aahz]
> ...
> For example, the recent work to resolve case-sensitive imports could
> be argued either way -- and if we want Python 2.0 to run on OS X,
> we'd better decide that it's a bugfix.  ;-)

[Guido]
> But the Windows change is clearly a feature,

Yes.

> so that can't be added to 2.0.1.

That's what Aahz is debating.

> We'll have to discuss this particular one.  If 2.0 doesn't
> work on MacOS X now, why couldn't MacOS X users install 2.1?  They
> can't have working code that breaks, can they?

You're a Giant Corporation that ships a multi-platform product, including
Python 2.0.  Since your IT dept is frightened of its own shadow, they won't
move to 2.1.  Since there is no bound to your greed, you figure that even if
there are only a dozen MacOS X users in the world, you could make 10 bucks
off of them if only you can talk PythonLabs into treating the lack of 2.0
MacOS X support as "a bug", getting PythonLabs to backstitch the port into a
2.0 follow-on (*calling* it 2.0.x serves to pacify your IT paranoids).  No
cost to you, and 10 extra dollars in your pocket.  Everyone wins <wink>.

There *are* some companies so unreasonable in their approach.  Replace "a
dozen" and "10 bucks" by much higher numbers, and the number of companies
mushrooms accordingly.

If we put out a release that actually did nothing except fix legitimate bugs,
PythonLabs may have enough fingers to count the number of downloads.  For
example, keen as *I* was to see a bugfix release for the infamous 1.5.2
"invalid tstate" bug, I didn't expect anyone would pick it up except for Mark
Hammond and the other guy who bumped into it (it was very important to them).
Other people simply won't pick it up unless and until they bump into the bug
it fixes, and due to the same "if it's not obviously broken, *any* change is
dangerous" fear that motivates everyone clinging to old releases by choice.

Curiously, I eventually got my Win95 box into a state where it routinely ran
for a solid week without crashing (the MTBF at the end was about 100x higher
than when I got the machine).  I didn't do that by avoiding MS updates, but
by installing *every* update they offered ASAP, even for subsystems I had no
intention of ever using.  That's the contrarian approach to keeping your
system maximally stable, relying on the observation that the code that works
best is extremely likely to be the code that the developers use themselves.

If someone thinks there's a market for Python bugfix releases that's worth
more than it costs, great -- they can get filthy rich off my appalling lack
of vision <wink>.

"worth-more-than-it-costs"-is-key-ly y'rs  - tim