What is the purpose of isCasedLetter:

[Ducasse]

isCasedLetter: char
"There are no ASCII Characters in this Category"
^ false

isCasedLetter: char
"There are no Unicode Characters in this Category"
^ false

isCasedLetter: char
^ Unicode isCasedLetter: char

so it is always false?

There are no sender.
I propose to remove it.

[Ducasse]

After reading and commenting all the class I think that this method should be moved to the testing unicode and can stay there.
BTW we always deprecate methods. I'm the guy that collect deprecated methods in the Migrator package. So I know what is deprecation and I practice it daily.
No need to get lessons. Now I do not like to deprecate full packages that can be loaded externally because we get a lot a code in the middle of our process for not much.

[astares]

@Ducasse

Yes - and if we apply it the way you described it will be different each time and totally confusing. The effect will simply be:

• Code that still calls a deprecated method in a still included package (normal or Deprecated80) is then able to work in the iteration release and can include a transformation (be migrated easily with due to the known deprecation or even automagic via transformation)
• Code that still calls a deprecated method in a deprecated but removed full package can not be migrated, and also a transformation makes no sense because the package is not available in this release anymore

These call will simply fail leaving the user confused - he can not know what happened because the package is not there anymore. It was not deprecated - it was removed and surprisingly disappeared
So he can not even check where the method is to see that it was deprecated and will have a hard time finding the right package to get it back in case it is just required or he want to find a new way doing things. So the user does not know where to find the package when he tries to load and adopt his code in the iteration release - and he has a bad surprise.

Why should we follow an own Pharo route of deprecation when there is a common and easy practice in software projects for deprecations equally for packages, classes, methods:

• you mark the artefact for removal and keep it at least one or more iterations so people get aware of the upcoming removal / migration situation
• then you remove in the next iteration

This is easy and gives a chance for easy adoption and follows what other technologies are doing as well. And we have so far followed such a model easily with

• using deprecations, moving to a "DeprecatedXXX" package as well as #isDeprecated
  on class side or manifest

I though we wanted to align with the outside non-Smalltalk world?

If you are up for a fast diet for the image then we can even hand out two images at release date: one

• Pharo80-compatibility (including the deprecated methods, classes) - easing migrations
• Pharo80-slim (with deprecations/deprecated packages already removed as we do in P9 iteration anyway)

[astares]

and for the records: they can not be loaded easily back (see https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2019-December/276980.html)

About package deprecation

[Ducasse]

You can send your advices to the Pharo board or the mailing-list and the community and the consortium crew can decide. I'm not involved anymore in such decision. I'm not in mailing-lists, I'm on discord anymore, I do not look at PRs, I do not add bug entries, I do not participate to public things, I quit the board. I do not want to have any public interaction around Pharo anymore.