On Sat, Aug 18, 2001 at 11:24:47AM -0700, Dan Ingalls < Dan at SqueakLand.org> wrote:
> 
> -- 
> Folks -
> 
> I'm afraid there is much more about all of this that I don't know than that I do
> know.  That said, perhaps it can be an advantage...
> 
> I know there are several things we are talking about here, and we need to separate
> them to come up with clear solutions.  What I'd like to do is to propose an 
> operational approach which may help to guide us to getting the 
> "best of both worlds" -- in this case a simple small kernel, but that can support
> a great group programming engine for large software projects.
> 
   ------------------SNIP-------------------------

Dan
    I agree with this proposal but would like to add a following requirement 
pertaining to versioning:

All modules within the system should have a major-minor version number.
Each module retains the major version number until the next release of the core.
Then each module major version number should be updated.
The minor version number of each module can be updated whenever there is a BUG fix, 
added functionality or changes in the implementation of the module.

It is important that each module should retain backwards compatability with previous
minor versions of the same major version of the module. Incorporating this measure
removes some of the restrictions placed on any dependencies for a particular version
of the module. eg. Dependencies for module FOO on module BAR can be stated as 
BAR >= vers xx.yyy where xx is the major version number and yyy is the minor version
number.

Whether this can be implemented to automatically download the related modules at the
installation of a new module or it has to be done manually after reading the new
module's prerequisites is for wiser heads than mine to decide.

HTH

John Briggs
-- 
Feeling exploited, impoverished or imprisoned??
Knock down the Gates of .... and break free into the "Brave GNU World" of the
"Free Software Foundation".
"Squeak" with delight at pleasure this freedom brings.