Eliminating upgrade risk

[Ian Parker]

In article <9k3s5m$9av$1 at panix2.panix.com>, Aahz Maruch <aahz at panix.com>
writes
>In article <3B656CBC.4F8FAFB2 at interet.com>,
>James C. Ahlstrom <jim at interet.com> wrote:
>>
>>But it would be naive to ignore the problem that Red Hat has
>>declined to upgrade from 1.5.2.  A quick
>>find | wc shows that Red Hat 7.1 has 84,494 lines of Python
>>code not counting the Python libraries.  I don't know how
>>Red Hat is supposed to upgrade Python and still know their
>>code works.
>
>That's a different issue.  Until June 2001, no version of Python after
>1.5.2 was GPL-compatible according to the FSF.  Now that 2.0.1 and 2.1.1
>are available, I expect that the various distributions will be
>upgrading.  Eric Raymond will make sure of that.  ;-)
>
>>BTW, it's not just the division proposal.  The change from
>>lst.append(x, y) to lst.append((x, y)) is another example.
>
>From what I see, the complaints about the division proposal are
>two-fold: silent breakage of old code and difficulty of maintaining
>cross-version code.  Neither of those points applies to the
>list.append() case, so few people have complained about that.

I have to support John Roth.  I've spent almost 20 years working in
organisations where reliability of systems is critical.  Most of my
background has been involved with OpenVMS systems.  Like IBM, Digital
tried exceptionally hard to avoid code-breakage with upgrades.  My
(normal) programs and scripts from the earliest versions of VMS can
still run on modern VMS systems.  Some code may need re-linking against
modern libraries, some may not.  

Why is compatibility so important?  Because these systems are very
complex, historical skills and knowledge are always lost and down-time
is very expensive.  It takes months to plan and schedule an upgrade to a
major system, and wherever possible you attempt to disengage the
developers (who have their own work to do) from the upgrade of the
production systems, because you can't involve all of the IT department
in every upgrade of the OS, layered software, compilers, database
software, etc.  

Remember also that in a large, complex system, you can't necessarily
roll-back if the upgrade doesn't work.  If it's a cluster of a dozen
alphas spread across two sites running all your critical applications,
or if it's a single trading system running across fifty Sun servers,
it's really difficult both to test in advance and to fix in a hurry.  So
when it doesn't work, you're down for a day and perhaps you're out of
the company, if the system's not operational by the next morning.  It's
even more upsetting when a global upgrade is required, and you find New
York doesn't work, after you've apparently successfully upgraded systems
from Japan to Europe.

So of course, you don't want incompatibilities introduced, and more
critically you don't want silent breakage of old code.

My tuppence-hapenny worth.

Regards

-- 
Ian Parker