Julian Fitzell julian@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