[squeak-dev] Re: Deprecation policy

> 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

Ralph wrote:
This is very interesting. Ralph is doing exactly what I have done in
Bob, planning ahead what should happen in future releases.
That is what Bob does in code, those steps are already coded. For
example the task #removeDeprecatedApi is already included in the task
that generates every new release.

You have just demonstated the reason for having a new release process,
that was called 3.11, the ability to encode the release process in such
a way as it can be repeated every 2 months or so, for test and "release
often" development.

Keith