For FileSystem, there is a clear win, so I'd say the change is really worth.

1) you add more capabilities

2) more logical/convenient API

3) more efficient implementation

4) more scalable implementation

The optional compatibility layer you offered is the exact solution to the upgrade problem (you give a bit of time to maintainers)

I buy it.

For and:and:and: etc... I agree with deprecation because such selector adds near to null
(I personnally changed many senders in Squeak, so I'm totally biased here).

For isNotNil I'm not convinced at all.

To me, it's not much but noise.

There are currently 3 senders vs 890 for notNil. I imagine many more in many packages.

Think in mid/long term. What's your plans? Wait for the balance to slowly inverse? Rename all?

For notEmpty, it's worse: 6 implementors.

So what's the new contract? any new implementor of notEmpty shall also implement isNotEmpty?

Or isNotEmpty is implemented in term of notEmpty in Object?

Currently, 5 out of 6 implementors of notEmpty do not implement isNotEmpty and 1 out of 2 implementor of isNotEmpty does not implement notEmpty.

It's not just noise, it's currently a mess!

As for an automated rewrite rule, yes, this is some very usefull features for supporting such refactorings.

I'd say a pre-requisite.

But that force using several branches for cross version support, or worse, cross dialect support.

If all diffs are automated, that's ok, if some of the changes are manual, it's a pain (backport etc...)

2013/7/17 Camillo Bruni <camillobruni@gmail.com>

there have been many similar decisions in the past,
I remember for instance the move from #and:and:and: or #or:or:or: which
weighs around the same as the #isNotNil.

FileSystem or Slots are even on a bigger scale.

Package maintenance in which sense, across different Pharo versions or different Smalltalk versions?

Between Pharo versions should be more or less ok, since such changes (#isNotNil and Co) usually come with a proper deprecation.

AFAIK there is someone working on detecting much more subtle changes in Pharo and provide lint rules on top. So I think we have to embrace changes.

On 2013-07-17, at 22:49, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
> I wonder what is the decision process behind such change.
> Do you put in balance what you gain and what you loose?
> To me gain is near zero and these little changes stacked together put a
> useless burden on package maintenance.
>
>
> 2013/7/17 Camillo Bruni <camillobruni@gmail.com>
>
>> On 2013-07-17, at 22:32, Nicolas Cellier <
>> nicolas.cellier.aka.nice@gmail.com> wrote:
>>> So you would be ready to change notNil -> isNotNil and become a bit more
>>> incompatible with the rest of the world?
>>
>> that method is already present in the image.
>>
>>> I understand that the pair isEmpty/isNotEmpty may seem a bit more
>>> homogeneous, but I see no other selector constructed with (isNot isnt)
>>> while I see many others where is is omitted.
>>> I wonder what this kind of change really serve...
>>
>> For me they are consistent with all the other is* methods out there
>> returning booleans.