Do you QA your Python? Was: 2.1 vs. 2.2

[Tim Peters]

[James Logajan]
> ...
> Many firms I've worked with get support contracts to only get bug fixes
> _and_ priority response when problems happen.

As before, you can buy that kind of support for Python now.  What you can't
do now is get it for free.  I'm not sure there's a real paying market for
it, either, as people who uncover a critical bug now *generally* get a fix
for it within a day or two for free.  If I were running a business, the
amount I'd be willing to pay to put an upper bound on the outlier cases is
approximately nothing -- provided I understood how open source works.

> (E.g. Database systems like Oracle.  Applications are designed assuming
> the existing feature set and behavior and it is nontrivial to rewrite a
> mission critical app to take advantage of some new feature.)

Sure, it can be.

> Whether the support contract includes delivery of new releases was
> rarely a consideration.

Python 2.1.1 and 2.1.2 and 2.1.3 and 2.2.1 were all "pure bugfix" releases:
they added no features over their base versions, and strived like hell not
to change any visible behavior (although that can't be achieved 100% --
bugfixes can break things too, and it's almost always the case that
*someone* mistook a bug for a feature).  It's economically impossible for us
to offer custom bugfixes that aren't released to everyone.  So bugfix
releases are a subset of "new releases" for Python.  If the developers
weren't predominantly Unixoids, I suppose we could make the commercial world
more at ease by calling them "service packs" instead <0.5 wink>.

> We never bought tools because of their future potential, we bought them
> because we thought they were relatively stable and would solve our
> problems then and there.

I'm skeptical of that for a programming language.  You're really going to
base your *infrastructure* on tools that won't grow to encompass technical
change?  Fine, stick with 1.5.2 and try to build internationalized apps
without Unicode; ignore SSL; say "who needs it?" to XML; "64 bit servers?
no thank you", "a 2GB file should be plenty for anyone"; etc etc.  It sounds
like an efficient strategy, but for a company that intends to go out of
business in protest when the market dares to change.

> ...
> Well, you know business requirements: the product should fit in a shirt
> pocket, have a 23 inch screen, run on a 9V battery for 3 years, and be
> capable of towing your car. ;-) This is why I now always demand a
> _prioritized_ list of requirements from marketing (and they can't
> all have the same priority!)

I bet the priorities shift radically with every new sales prospect anyway --
the commercial world isn't unknown to me <wink>.