[plt-scheme] On PLaneT packages and compatible upgrades

At Wed, 10 May 2006 10:18:53 -0400, Eli Barzilay wrote:
> On May 10, Matthew Flatt wrote:
> > At Wed, 10 May 2006 07:58:01 -0400, Matthias Felleisen wrote:
> > > I would very much prefer a tool -- "Compatible Extension" -- that
> > > consumes two modules and either says "yes" or lists the things
> > > that one module exports and the other doesn't. In addition, it
> > > should come with an option "Generate Adapter," which produces a
> > > module m- with the same interface as m.v0 but with values from
> > > m.v1. (This should be N+2 lines: module, import plus one export
> > > per m.v0 interface.)
> > 
> > This took me a while to understand. I'll repeat it back just to see
> > if I do understand:
> > 
> >  1. Adding exports is not a compatible upgrade.
> > 
> >  2. Suppose the only change between version N.M and (N+1).0 is bug
> >     fixes plus new exports. In that case, it's trivial to implement
> >     version N.(M+1) in a way that captures future bug fixes in the
> >     (N+1).* series: import (N+1).*, then re-export everything that
> >     was exported from version N.M.
> > 
> >  3. Since the implementation of N.(M+1) is trivial given N.M and
> >     (N+1).0, it would be nice to have a tool that does it for you.
> > 
> >  4. Also, library implementors should also use a tool to double-check
> >     that any implementation K.(J+1) is a compatible extension of K.J
> >     (i.e., it has the same exports).
> > 
> > Is that right? If so, I like it.
> 
> What I don't like about all this is that it's based only on names.  I
> also don't like the assumption that using version (N+1).K it is
> possible to `compute' version N.(M+K) -- it feels like a fragile
> assumption, and it doesn't feel right to generate automatic versions
> where the author didn't mean for them to exist (=> how would you feel
> about an automatically created PLT v210?).

It sounds like you need to provide a translation of my translation of
Matthias's original message.

I mean that version N.(M+1) exists only because the author of the
library explicitly decides to implement it. And if it's a trivial
implementation in terms of version (N+1).0, then the library author can
automate the implementation by running a tool. In no other sense,
however, does version N.(M+1) exist automatically.

> What if I want to remove bindings, or change the way some existing
> binding behaves, like adding an argument or changing what it does?

We agree: you certainly shouldn't implement version N.(M+1) in terms of
version (N+1).0.

> What I would prefer is that every time I release a new version N+1, I
> provide my own version N compatibility layer in the form of a new
> module

Exactly.

Matthew