On 17 Aug 2012, at 17:55, Esteban Lorenzano <
[hidden email]> wrote:
> Issue 3459: includesSubstring: aString caseSensitive: caseSensitive / includesSubString:
>
http://code.google.com/p/pharo/issues/detail?id=3459(I commented on the issue, but the mail did not come through).
I know that we have been here before, but how are library writers that target multiple pharo versions (1.3, 1.4, 2.0) supposed to handle this ?
If I track the 2.0 selector name, I break pre-2.0 compatibility.
If I don't track the rename, I get massive deprecation warnings in 2.0.
I am all for progress and cleanups, but can we ask library writers to deal with this alone ?
We could talk about this at ESUG.
---
An idea could be to make a 'PharoForwardCompatibility' package to be loaded in 1.3 or 1.4 with minor additions or changes to help here. For example, in this particular case, the differently spelled new methods could be added as synonyms. This way library writer can track the lastest 2.0+ API, while maintaining backwards compatibility. If we maintain this as a community, it would be a very useful shared resource. I also think that it would allow the lastest version to evolve faster.
Comments ?
Sven
Locked
