On Thursday, May 22, 2003, at 09:59  AM, goran.krampe at bluefish.se wrote:

> Yes, of course conflicts will arise! But there are two things that will
> make this work (I have described this tons of times, I really need to
> put it on a webpage):
>
> 1. A packagerelease can have *multiple* working configs. So if A and B
> worked with C-1.0 that would be known in other configs. And the engine
> could find that! This is very important. So if at the time of release 
> of
> package A there was C-1.0 and C-1.1 available, the maintainer (or
> others) can test both and simply register two working configs. But they
> *should not* claim that package A works with C-2.0 because that version
> *does not exist yet*. They simply can't predict the future.
>
> 2. If there is still a conflict another basic idea of mine comes into
> play: "compatibility level". I want to force PackageReleases to declare
> how "backwards compatible" they are. I have a list of 6 levels - but we
> can discuss those of course. But just as an example - if C-2.0 has
> compat level 1 (=No change actually, just better class comments etc)
> then the engine can tell you that and offer you to use C-2.0 with
> package A and it would not be a problem. If the level was 6 (=The API 
> is
> totally changed, no chance in hell that dependents will work) then the
> engine can tell you that and you would realize that you are stuck.
> BUT... the engine can also tell the developer of package A that he/she
> probably should upgrade because the dependency on C-1.5 is creating
> conflicts!

The only thing missing here is a way to specify *broken* configs. Say 
that C-2.0 is released, and it has a compatibility level of 2 with with 
C-1.5. It's a minor change, but it happens to completely hose A-1.0. 
The package loader should be able to tell you that "Loading C-2.0 will 
break A, but if you upgrade A to 1.1, 1.2 or 1.7 all will be well."

cwp


Colin Putney
Whistler.com