Hi again,

> You release Apple as:
> Apple 1.0 depends on Banana 1.0 and Orange 1.0
>
> I release FruitBasket as:
> FruitBasket 1.0 depends on Apple 1.0
>
> Then you discover that, hey - it Apple 1.0 also works with Orange 1.1 
> so
> you release:
> Apple 1.1 depends on Banana 1.0 and Orange 1.1
>
> (note: If you go this route you will also start looking for using
> booleans so you would really have liked to say:
>     Apple 1.1 depends on Banana 1.0 and (Orange 1.0 or Orange 1.1)
> ...which is what Debian's package system does. Personally I do not want
> to go there, it just gets so messy and complicated)
>
> Now, my package release FruitBasket 1.0 still refers to Apple 1.0 so
> your new discovery that Orange 1.1 is OK is just lost to FruitBasket!
> And then someone tells me, and oops - cascade - I must also make a new
> release just because you did one. Sigh. ;-)
I think that it would be dangerous for you to assume that this would 
work
out of the box. Maybe fruitbasket starts to rot if it included Orange 
1.1, no?
But see below, this would work perfectly fine with my proposition as 
well.
>>>  thus you get "cascading
>>> changes" which will simply create a big soup of releases that are 
>>> only
>>> meant to "adjust" the dependency information.
>> I thought we agreed on the fact, that both our solutions are facing
>> that problem,
>
> Eh, where did we agree on that? I don't! :-) :-) In my model package
> configurations only have a *current* version. I don't keep track of the
> old ones. So if a new configuration is discovered - sure, I add it. But
> it doesn't produce new releases of the packages as a side effect.
You keep on creating configurations while I create versions. That is it.
Nothing more nothing less...

In my model the whole fruitbasket also can be loaded together
with the most hip versions of its prerequisites, if you want.
It is just not acknowledged at that time, that this works.
If somebody trusted acknowledges, fine, make it a baseline-version.
(1 click technique)
  I really don't see any difference here to your model which makes it a 
configuration.
> regards, Göran
>
> PS. I hear you are thinking in terms of team development/Envy. Please
> remember that packages/SM is not the same thing. It obeys different
> social mechanics, different expectations, timespans etc. Envy might 
> cope
> fine with explosions of versions etc - but that is not what I want in
> SM.
Which exactly? Why are they not covered by my model?
Actually I would be very interested in your thoughts about my ideas to 
integrate
the SqueakPeople trust model in SM* here.

Regards,

Markus