Important for 3.9 submissions and fixes
stéphane ducasse
ducasse at iam.unibe.ch
Sat Sep 10 20:14:56 UTC 2005
On 10 sept. 05, at 21:39, Daniel Vainsencher wrote:
>
>
> Avi Bryant wrote:
>
>> Actually, I think either way would work, because IIRC Monticello
>> doesn't actually use dependencies as a way to specify ordering,
>> simply as a way to figure out which versions of which packages to
>> load together. It then dumps all of the methods and classes into
>> a big pool and sorts out the load order itself. As long as you
>> make sure to load M.2 and E.2 at the same time, you should be fine.
>>
> I was talking about this aspect, not about internal ordering of
> loads. We want to make it impossible to load M.2 without loading E.
> 2, and AFAIU, a dependency M.2->E.2 achieves that. OTOH, a
> dependency E.2->M.2 would allow me to load M.2 alone, which would
> remove functionality. Am I right?
Daniel hardcoding dependency at version level for the loading can be
a pain after because you can arrive to situation where you need
to load a different version of component but you cannot unload it to
load its new version.
> If so, that allows contributors to distribute their new versions in
> a form that specifies precisely how they need to be loaded, and
> then a maintainer doesn't have to figure it out, and we don't have
> to go back to change sets.
I think that having Configuration like the
MCVersionLoader new
addVersion: ...;
addVersion: ...;
addVersion: ...;
load
is a good solution since we can define a new one without having to
load in the image a component.
We can just change the script. I'm sure that I'm not clear but we are
bitten by the version prerequisite syndrome in
VW for moose. And now I'm dead.
>> As Marcus mentioned earlier, our current configurations system
>> *doesn't* do this - it's trying to enforce a particular order, and
>> so loads every package individually. All in all, I think this is
>> a mistake. In the rare cases where Monticello can't get the
>> order right on its own, we can post sequential configurations to
>> the update stream to force its hand. Otherwise, I think we
>> should be doing it as a bulk load.
>>
> Sounds right to me.
>
> Daniel
>
>
More information about the Squeak-dev
mailing list
|