[SM]Plan...

Andreas Raab andreas.raab at gmx.de
Tue Aug 3 23:19:08 UTC 2004


Hi Guys,

Just out of curiosity: Why is it necessary to go to the length that you are
proposing with respect to the compatibility levels? It seems to me that a
maintainer might be hard pressed to distinguish between CC 1 and 2 (I
couldn't possibly imagine that absolutely no app would ever be able to use a
changed package; so I'd probably always opt on the side of 2) as well as 3
and 4 (how exactly do we define "not changed any old code"?) or 5 and 6. It
seems to me that we might be able to simplify this by saying we have three
major compatibility levels:
* interface/semantics unchanged (known to be compatible) (5 and 6)
* interface/semantics (expected to be) compatible (3 and 4)
* interface/semantics (expected to be) incompatible (1 and 2)
With possibly being able to further distinguish (if that is needed). At
least for me, describing the compatibility level by using the above three
levels would be much simpler than the six levels proposed and (judging from
practice) these are precisely the levels that I typically care about as a
client.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Stephan Rudlof" <sr at evolgo.de>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, August 03, 2004 3:58 PM
Subject: Re: [SM]Plan...


> Göran and all,
>
> goran.krampe at bluefish.se wrote:
> > ...
>
> > Now - how does the current dependency plan look? Well, Stephan and I are
> > exchanging thoughts and it looks "approximately" like this:
> >
> > - We both rely on the maintainers to enter "compatibility level"
> > information when registering new releases on SM. My model would have
> > been a single drop down menu selection. Stephan's richer model would
> > mean a multi select list with circa 6 items in it. So both are easy
> > enough and we will probably go for a unified variant.
>
> I think for my model the drop down menu selection would suffice to! See
> Swiki page about 'compatibility codes':
>   http://minnow.cc.gatech.edu/squeak/3792
> , and especially the questions to the package maintainers to be
> answered: one of them answered with 'yes' should be sufficient.
>
> Note: The page doesn't comprise all aspects, which it should comprise,
> so far, but I'm interested in *all* kinds of feedback (especially if it
> is understandable already) yet.
>
> >
> > - I am focusing on "configurations" and "anti-configurations" and a
> > dependency engine based on those.
> >
> > - Stephan adds a few other concepts to the model, especially his Caps
> > and Transformations.
>
> For me it makes sense to use the "configurations" and especially the
> "anti-configurations", too: they are valuable informations given by the
> users usable for *every* dependency resolving system.
>
> >
> > To us it currently seems like we can experiment with both these models
> > in conjunction and
>
> Agreed.
>
> > I will make sure SM supports Stephan and his needs to
> > try his additions
>
> Thanks.
> I highly appreciate the discussions with Göran about this complex domain
> happening in a very constructive athmosphere! (Though they have led to
> the longest mails I've ever written...)
>
> > - when his design has stabilized.
>
> Which will take a while ;-)
> For me the concept of the 'compatibility codes' already has stabilized,
> and I have tried to explain it from a praxis POV in the mentioned Swiki
> page; so that can be treated as 'state of the art'.
> But while thinking about the dependency resolving mechanism some new
> aspects have appeared (especially the difference between pre- and
> post-requirements), which enriches the needed algorithms ;-)
>
> Note: With pre-requirements I mean preconditions to be fulfilled
> *before* e.g. installing one package version, whereas post-requirements
> have to be fulfilled at the *end* of the *whole* installation process of
> all package versions to be installed, to get a working system. This
> makes a *big* difference. Both sets are requirements for a working
> package, though, and in addition these sets often won't be disjunct.
>
>
> Greetings
> Stephan
>
> > ...
>




More information about the Squeak-dev mailing list