[Modules] as a inital focus

Dave dave at bedarra.com
Fri Aug 17 01:31:43 UTC 2001


I believe we should take Allen's advice as the "last word" on this and
focus on
the module structure in the [Modules] topic. The other issues are both
very interesting and very important but need and more than justify their
own discussion threads [Version Management]; [Configuration Management];
[ Repositories]; [External Source and Binary Format]; [Separation of
Development and Runtime] ... 

Dave Thomas
Old Country Programmer

Allen Wirfs-Brock wrote:
> 
> 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