Re: Deprecation, repackaging, and compatibility

Moving a type from one package to another creates a new type.  Compatibility
requires either source changes in the client, or a proxy class in the old
package.

With respect to method changes, given existing type E, old type O, new type
N:

Case #1:

   void E.m(O) => void E.m(N)

Short form: A solution is to have both signatures, and provide the name of
the jar containing O.

Long form: This can be handled by adding a new method and deprecating the
existing one.  No real issue from my perspective if Berin wants to push O
into a compatibility jar, so long as the latter does exist, and we're told
where.  :-)

With respect to CVS vs release, GUMP promotes that such changes be committed
at the same time or within some reasonable timeframe, because otherwise GUMP
cannot provide its continuous integration function.

Case #2:

   O E.m() => N E.m()

   #2.1   O = E.m(); // compatibility requires N extends O
   #2.2   f(E.m());  // either N extends O, or add f(N)

If N does not extend O, the change is incompatible.  If N extends O, the
change is source compatible because N can be promoted to O.  In the current
case, it means a new class would be extending a deprecated one, but it does
compile.  Binary compatibility is also a concern.

	--- Noel