sounds like a good idea. Now how could we make that as easy as possible for doing it. We should produce two slices one for 3 and one for 4 Stef On 15/9/14 09:16, Marcus Denker wrote:
Hi,
In case we rename methods that are used as part of the public API, I propose to do
1) add the same API to the current stable version (today this would be Pharo3 2) add a rule (in a âPort Pharo3 to Pharo4â category that finds the needed senders (if possible even with a transformation)
Then depending on the use and importance
-> deprecate the old API right away or -> just tag it as âto be deprecatedâ one version later or -> keep the old as âcompatibilityâ
This should make it possible to clean up API (e.g. when there are typos in the selectorâ¦), while not disturbing users to much. *And* it will be possible to have affected code running both in Stable and Development.
(This should not be a strict rule, more a âbest effortâ one, and there will always be cases where we can not do this or where it is not needed).
Marcus