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
On Mon, Sep 15, 2014 at 9:16 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
1) add the same API to the current stable version
this one would be great because I had problems with the FileSystem API between Pharo 2 and Pharo 3: in Pharo 3 I had deprecated warnings that I could not fix because Pharo 2 did not have the new API. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
On 15 Sep 2014, at 09:35, Damien Cassou <damien.cassou@gmail.com> wrote:
On Mon, Sep 15, 2014 at 9:16 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
1) add the same API to the current stable version
this one would be great because I had problems with the FileSystem API between Pharo 2 and Pharo 3: in Pharo 3 I had deprecated warnings that I could not fix because Pharo 2 did not have the new API.
Yes, but it is clear that sometimes it is just too much work. e.g we can (by definition) not put everything new in Pharo4 in Pharo3. So this should be seen as a âbest effortâ rule... Marcus
On 15 Sep 2014, at 09:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Yes, but it is clear that sometimes it is just too much work. e.g we can (by definition) not put everything new in Pharo4 in Pharo3.
So this should be seen as a âbest effortâ rule...
Putting that best-effort practice into place would already be a big plus. Though I see no reason to not pass method renames through a deprecation status. They can never be *that* urgent, and itâs quite easy to deprecate them and remove them in the next version. Keep up the good work! cheers Johan
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
participants (4)
-
Damien Cassou -
Johan Brichau -
Marcus Denker -
stepharo