Hello All,

goran.krampe at bluefish.se wrote:
> Hi Trygve and all!
> 
> Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> 
>>There has been many suggestions about how a package can survive a change in 
>>its class library. I believe the only workable solution is to let a package 
>>include all required objects and ignore any new versions that may come along.
> 
> 

> It is worth to note here that the compatibility level idea is not meant
> to be the fundamental mechanism in the dependency model - it is instead
> meant as guidance, especially when the combination of packages creates
> conflicts in version (Package A1.0 needs B1.0 but C1.1 needs the newer
> B1.1) and you might need to try using a newer release that hasn't been
> tested yet.
> 
> So... the idea is to use the tested specific releases of required
> packages - just like you say - if there is no conflict. But when
> conflicts arise the idea is to be able to get guidance in trying new
> combinations.

My view is slightly different: I would like to give the compatibility
level mechanism more importance.

For me the compatibility level mechanism could serve as one base for
automatically upgrading.
Upgrading a lib for a new package, while staying compatible with other
packages written for an older version of this lib, is just *one* case of
automatically upgrading.
Note: this does not hinder an UI to ask the user for confirmation of the
suggested moves.

The compatibility information could be one filter for package versions
to be chosen as upgrade candidates. In an ideal world this would be
sufficient! In a not ideal world 'working configurations' and 'not
working configurations' (the latter may be used for automatically
expressing them as conflicts) are other informations well suited to
improve the chances for a successful upgrade.


Göran seems to see the importance of these filters the other way around:
but this is somewhat naturally and it should be possible to control and
prioritize these filters by policies.
But the effectiveness of *both* highly depends on the participation of
the people: the compatibility info more from the package maintainers,
the working/not-working configuration info more from all users.


Greetings
Stephan

>...