[Modules] finding the little buggers

Allen Wirfs-Brock Allen_Wirfs-Brock at Instantiations.com
Fri Aug 17 01:03:00 UTC 2001


At 03:17 PM 8/16/2001 -0700, Jan Bottorff wrote:
>My experience has been, developers track record on "backward compatible" 
>new versions of modules is not so good. It seems like one goal of 
>package/dependency management is to ASSURE a piece of code will be in a 
>compatible environment. To me, this means the developer has tested the 
>code with a specific permutation of updated external modules, and has 
>nothing to do with the external module supplier assuring you "it's 
>compatible". As the number of permutations grows rapidly with the number 
>of modules, it seems like the farther you get from an exact tested module 
>configuration, the greater the chance of flaws.

Totally agree.

My sense is that modularity, version management, and configuration 
management are best dealt with as separate orthogonal dimensions.  Modules 
provide structure and control granularity. Versions track the evolution of 
modules. Configurations identify specific sets of module versions.

Assume that you have two Modules M1 and M2 that both depend upon Module M3. 
Also assume that all three modules are under going change (bug fixes, 
feature enhancements, etc.) When you ship M1 and M2 (actually specific 
versions of M1 and M2) you want to be sure that it is in conjunction with a 
version of M3 that is known to work (has been tested with) with those 
versions of M1 and M2.

One way to do this is to record a dependency within M1 upon a specific 
version of M2 (pardon the totally ad hoc syntax):

         M1 (V1.5) = { requires M3 (V2.7) ...}
         M2 (V9.8) = { requires M3 (V2.7) ...}

This means that if a new version of M3, is created and you want to use it 
you have to create new versions both M1 and M2 so they can require the new 
version of M3:

         M1 (V1.6) = { requires M3 (V2.8) ...}
         M2 (V9.9) = { requires M3 (V2.8) ...}

If M3 is required by dozens of modules you would have to revise each of 
them in order to build a system using the new version of M3.

Alternately, you can separate the configuration information from the 
modules.  So M1 and M2 would be defined as:
         M1 (v1.5) = {requires M3 ...}
         M2 (V9.8) = { requires M3  ...}

and you would define a separate configuration specification:
         M123-Config (3.2) = [M1 (v1.5) + M2 V(9.8)+ M3(2.7)]

(Configurations can be modified, so they also need to be versioned)  When 
M3 is revised you don't change M1&M2, you just create a new configuration 
version:
         M123-Config (3.3)  = [M1 (v1.5) + M2 V(9.8)+ M3(2.8)]

The economies of scale become even most obvious when dealing with larger 
numbers of modules.

It's quite possible (and I would argue desirable) to design module 
structure, version management, and configuration management in phases and 
layers.  Start with a module specification that describe program structure. 
(could be stored in a file or image or where ever). Upon that layer a 
versioning scheme for identifying revisions of modules. (could be encoded 
file names, or CVS, or a RDMS, in image, etc.Multiple alternatives are 
fine).  Finally, add a configuration layer for making sure you are using 
the correct versions.)

Allen Wirfs-Brock
         





More information about the Squeak-dev mailing list