On 17 September 2012 13:55, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 2012-09-16, at 03:19, Levente Uzonyi <leves at elte.hu> wrote:
>
>> I didn't remove the methods from Utilities because I want to deprecate them first, but before they are deprecated, the senders from the Trunk packages have to be rewritten.
>
> +1
>
> We tried proper deprecation in the past and it were not that thorough, but we should try again. That is, move deprecated classes/methods into a "Deprecated-in-4.4" package and keep that loaded by default at least for one more release, but remove it at some point.

Enforcing the deprecation's relatively easy: we need just add a step
to releasing a version N that removes the deprecated packages for N-2,
N-3, ... That way we'd keep one round of deprecations.

The "need to be more thorough" bit I guess is what you mean, in
particular: marking something as deprecated will still be manual.

frank

>> Colin proposed that multiple instances might be useful, though I still don't see any real world use cases for it, but I'm not against not overriding #new.
>
> The one use case I encounter quite often is temporarily setting different initials for generated methods. Might be useful for tests too.
>
> - Bert -
>
>
>