[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
|