There has been many suggestions about how a package can survive a change in its class library. I believe the only workable solution is to let a package include all required objects and ignore any new versions that may come along.
Example 1: In a very early version of Tektronix Smalltalk, we compensated a off-by-one error in a library class by adding 1 in the subclass. We then got a new and corrected version of the library. Out application was again off-by-one...
Example 2: A program working with bitmapped graphics worked perfectly until we got a new version of the VW class library. Our response time then went up from milliseconds to hours. There were no interface changes, but a library class that formerly cashed a transformed bitmap now computed it afresh at every request. Cashing it outside the inner loop in the app method got us back to millisecond response time.
Example 3: "On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off[...]It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed." Here it was the same program using the same library, it was merely a faster rocket.
The surface area between a system of classes and their superclasses is enormous, there is no way the library developer can foresee the effect of a change on the many and unknown users of the library. My own experience is also that it is practically impossible for an application developer to see the effect of hundreds of changes in the library even if they are carefully listed (as PPS used to do).
The solution I dream about for BabyUML is that it shall support many versions of a class simultaneously. Library classes shall not be known by name, but by object ID. The loading of a package should automatically cause the loading of the objects it requires if they are not in the image already. Object IDs must be unique in time and space. I estimate 90 bits, but local aliasing should be possible for efficiency. It seems sensible to use a finer granularity than class objects, "Traits" looks very promising in this context.
Finally, testing can only show the presence of bugs and not the absence of bugs. Bug free software takes bug free design and bug free implementation. The purpose of testing should only be to confirm that everything is OK. But our present programming paradigms do not yield readable programs. The goal of the BabyUML project is to make it practicable to create simple solutions to complex problems.
Cheers --Trygve