> I would like to suggest that we develop a formal deprecation policy.  It
> could be as simple as deprecate in one release, remove in the next.  I
> just think we need to be consistent about it and remove no individual
> methods without following it.  How this relates to the idea of
> repackaging and removing whole categories of classes, I'm not so sure.

> Ken

How about the following.  In Squeak 3.11 we add a method deprecated3.11
in Object which does nothing and is called by each deprecated method.
When Squeak 3.12 (say) is released it has a method deprecated3.12 for
newly deprecated methods.  Meanwhile method deprecated3.11 now
generates an error if invoked.  When  Squeak  3.13 is released all methods
that invoke deprecated3.11 are removed and deprecated3.12 now generates
an error.  Of course all newly deprecated methods in Squeak 3.13 invoke a
new method in object called deprecated3.13 which does nothing.  etc.

For deprecated classes in Squeak 3.11 we implement a method
deprecatedClass3.11 which is invoked by each deprecated class's new
method and implemented in Object class.  It does nothing for Squeak
3.11 and generates an
error in Squeak  3.12.  In Squeak 3.13  it disappears along with the
classes that
invoke it.

Note that users can easily remove or modify the deprecation methods or
invocations to suit their purposes.  They know what they are doing and
implicitly are prepared to live with the consequences.

Ralph Boland