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, 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.

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.

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.


-Lex