[Squeakfoundation]A bit about SM1.1 and dependencies

Daniel Vainsencher danielv at netvision.net.il
Wed Feb 12 18:22:21 CET 2003


goran.hultgren at bluefish.se wrote:
> Daniel Vainsencher <danielv at netvision.net.il> wrote:
> > Ok, just to show what I mean. Suppose I make a package type that holds a
> > single method that goes something like
> > ^#((RBModel 1.09)
> > (RBGUI 1.06)
> > (RBTests 1.05))
> > 
> > Then I write a service that loads this kind of package, and does
> > packagesList collect: [:packagePair | SMSqueakMap loadPackage:
> > packagePair first version: packagePair second].
> > 
> > Or maybe something a little more complicated, but you can see where I'm
> > going... I don't need much more support.
> 
> Ok, this looks to me like "virtual packages". A package that has no
> content and loads specific versions of other packages. In fact - this is
> a "static load script" given my previous terminology. (Static in the
> sense that it will always result in the same package releases being
> loaded)
Not exactly - note that the code interpreting the list is outside the
list, in a service. The code here is just a way to store the
instructions.

> But this plan doesn't AFAICT make it possible to have multiple possible
> configurations for RB. I assume that the virtual package/load script you
> described above would be "RB".
Actually it does - there's nothing stopping me from concurrently also
publishing another package that also specifies the RB Components, at
different versions. For example -
^#((RBModel 1.1)(RBGUI latest)(RBTests latest)(RBRewriteRuleEditor
latest))

could represent the right configuration for someone that want to play
with the latest GUIs, but using a known stable model. The two can
definitely coexist - each is it's own package (I don't know what you
mean by virtual), and even be authored by different package maintainers.

> It would also mean that you need to make a new version of RB if you want
> to change the dependencies for RB - so you get "cascading version
> changes" - package Y is released in a new version and X depend on it so
> must also be released in a new version etc. etc.
No, why?
The only time I'll have to update depedencies, is when I have a stable
configuration, and I've decided that a newer version deserves to be
point to in it. And I don't see many ways to go around that...

Daniel Vainsencher


More information about the Squeakfoundation mailing list