Lex,

lex at cc.gatech.edu wrote:
> Stephan Rudlof <sr at evolgo.de> wrote:
> 
>>lex at cc.gatech.edu wrote:
>>
>>>Stephan Rudlof <sr at evolgo.de> wrote:
>>>
>>>
>>>>One remark regaring mixing: I think it is possible to mix.
>>>>
> 
> [...]
> 
>>>>E.g. they had to give some hints about how compatible a package from one
>>>>universe is in the other one, in *addition* to the normal hints about
>>>>how compatible it is in just one.
>>
>>>Note that the "hint" could be:
>>>
>>>	A addPackage: P
>>
>>this hint doesn't help. Just adding the package to another universe
>>doesn't say anything about its compatibility in it. You need another
>>'measurement' related to the new universe.
> 
> 
> I was talking about how you *record* the hint,

But I was talkin about "they had to give some hints about
*** how compatible ***
a package from one universe is in the other one" (see above!)...

> not about how you measure
> it.  Instead of having an annotation on P that says "I seem to work in
> A", you can simply add P to A.  This is a very important point.  It is
> pretty much the definition of what a universe is.

OK.
But you also have to add a compatibility measurement for each package
version for each new universe (as you have stated below, too).

> 
> It also means you don't need to mix.
> 
> Regarding compatibility codes: they sound very nice in themselves.

:)

> The
> main thing that worries me is that "backwards compatibility" is a tough
> question if you do not have any context about what other stuff will be
> loaded in the image.  Let me give three examples.
> 
> One example is that you may want an update to be "compatible" for the
> purposes of an unstable universe, but not compatible for people working
> in a stable universe.  You may know there are some bugs in obscure
> cases, but you may still want the auto-installer to offer your package
> to people working in the development universe.  Whether you say the
> update is compatible or not, it will be wrong for the many people
> operating in one universe or the other.
> 
> Another example would be where I make a new version of a package and
> have it use the new LargeList selectors.  Is this backwards compatible? 
> In a 3.7 image, this is perfectly backwards compatible, because it has
> LargeLists in it.  In a 3.6 image, the code will stop working entirely,
> so it is surely not a compatible upgrade.  How do I mark this?  However
> you mark it, is going to be incorrect for many people.
> 
> A third example would be if you remove a method that was deprecated in
> 3.4.  That's completely backwards compatible in a 3.7-based universe,
> because no one is calling the method any longer, but of course it breaks
> compatibility in a 3.4-based universe.
> 

Your examples are good for illustrating my original point.

> All of the above questions are easy if you know which universe you are
> talking about, and unanswerable otherwise.  Thus, it seems that
> compatibility codes should be associated with (universe,package) tuples,
> not with bare packages.

Exactly (if packages are package versions/releases (I've been sloppy
here above, too))!

But it is also possible to put these as (universeAttribute (e.g.
Squeak3.7), package version (!), compatibility) tuples in one universe,
isn't it?


Greetings
Stephan

> 
> 
> -Lex
> 
> 

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3