Path: utzoo!mnetor!uunet!husc6!ukma!psuvm.bitnet!uh2
From: UH2@PSUVM.BITNET (Lee Sailer)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Message-ID: <35461UH2@PSUVM>
Date: 9 Mar 88 16:58:20 GMT
References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP> <2985@metavax.UUCP> <34359UH2@PSUVM> <667@kajak.cs.vu.nl>
Organization: Penn Sate Erie--School of Business
Lines: 19

In article <667@kajak.cs.vu.nl>, jos@cs.vu.nl (Jos Warmer) says:
>
>The day things went wrong, they had a new version of the VMS
>C compiler installed, including of course the (shared) libraries.
>The errors in the unchanged working program emerged from an
>error in the new libraries.
>

Shared library systems should have some mechanism for avoiding this type
of problem.  How about this:

When object files are created, the startup code includes a check of the
version of the library used.  Then, if the library changes, the startup
code sends urgent mail to the person responsible for supporting the code,
such as the local system administrator, the vendors (via email?), and the
user (this is optional).

Another approach would be to keep the old libraries around, and have
the using object file specify a library version number.