Ralph wrote:
> 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.
>
>   

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