Julian Fitzell <julian at beta4.com> wrote:
[SNIP]
> > Does this seem reasonable?
> 
> Yes, I had somewhat forgotten that we were thinking of configurations 
> and not of individual dependencies.  It seemed reasonable when Goran 
> explained it to me at OOPSLA and still does... just that I'd forgotten :)

:-) Need to write that down somewhere permanent.

> I was pretty sure you were only talking about installers, but I wanted 
> to make sure.
> 
> Goran, configurations are associated with package *versions* I assume? 

Exactly. I call them "package releases". There is a new class called
SMPackageRelease in SM 1.1.

> So I can say in a configuration for Seaside, for example, that Seaside 
> works with Comanche 5.0 and then any valid configuration for Comanche 
> 5.0 would meet that requirement?

In the SM 1.1+ that I envision the answer is yes, at least if you mean
"in a configuration for Seaside version x". Package configurations are
per "package release".

Big sidenote:

SM1.1 which I am working HARD on (I started refactoring a LOT to make it
simpler etc) will introduce most importantly SMPackageRelease. It will
also introduce 2 more things that you can register on SM making it a
grand total of 3 (or 4 counting SMPackageRelease but they are part of an
SMPackage):

1. SMPackage (formerly known as SMCard, holds an OrderedCollection of
SMPackageRelease)
2. SMResource (Similar to the current SMCard in that it knows its
current version but no releases. A resource is meant to capture anything
that is NOT a package - it is typically a downloadable "something".).
3. SMPerson (one of the few things that isn't an SMReource. :-)

Now - where are the "package configurations" I have been talking about?
Aha! They aren't there! :-) I instead put down the foot and said - "No,
SqueakMap ends HERE." and created SMResource instead.

So my upcoming model for dealing with dependencies through "package
configurations" will be a layer *on top* of SqueakMap and the "package
configurations" will be registered in SM as SMResources that are then
linked (using SMLink - a new thing) to the SMPackageRelease they refer
to.

One very nice property of this is that we don't build a model for
dependencies into SM. If someone else can implement something cooler
than my model then the playfield will still be open.

regards, Göran