I think an interface (protocol) based solution to this issue is the best
way to go...for example:

You create a package called "Foo".  But, the name "Foo" not only
represents the package implementation, but also its interface.
Therefore, why not separate the interface from the implementation, and
call the package "Foo.09082001.svp" or something, and indicate that it
implements the "package interface" called "Foo".  Subsequent versions
will also indicate that they implement the package interface "Foo",
unless they are not backward compatible, in which case, the supported
interface would be "Foo.2" (or something).  It might be handy to
separate the interface name and version as well.

A package requiring "Foo" will gladly accept any package that claims to
implement the "Foo" interface.  A package could also specify a range of
package interfaces that are acceptable (like requiring at least
"Foo.2").

Thus, it would be possible to write packages that implement more than
one package interface.  Eventually, the "package interface" could be
reified such that it would be possible to determine if a package
actually implements the interfaces it claims to support...and, it would
be possible for a package implementor to specify the public interface to
the package (ensuring that clients only use the public interface, and
other would be implementors of the interface know what is expected of
them).

All of this could be tied together with a hierarchical scheme for
locating implementors of a given package interface (for example, looking
first within the image, then on a local disk, then out on the net...or
some other custom lookup order).

- Stephen


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Ned Konz
> Sent: Thursday, August 09, 2001 12:41 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: A Squeak Packaging Proposal (Re: Is this list a 
> chat or a list REALLY ?)
> 
> 
> On Thursday 09 August 2001 08:52 am, you wrote:
> > All packages will have a globally unique id (generated from the 
> > current millisecond time plus a random number plus the authors 
> > initials) so they can be uniquely identitfied.  You make changes by 
> > creating a new package.  If you name it the same as an old 
> package the 
> > user will see this and can choose to use it in future 
> packages instead 
> > of the old one.  The new package can have the old package as a 
> > prerequisite.
> 
> How would it be possible to allow prerequisites in a range of 
> _versions_? For 
> instance, I may make a package that requires at least version 
> 1.02 of another 
> package (in conventional terms), but I know that version 1.23 
> of that package 
> breaks mine. So I'd like to specify a dependency on one of a 
> range of package 
> versions (including ones I maybe haven't seen yet, and so 
> wouldn't know the 
> GUID of).
> 
> -- 
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com
> 
>