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