On Tue, Mar 3, 2015 at 9:37 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Sven Van Caekenberghe-2 wrote
> Yes, maybe this could be made more consistent in Pharo 5, but it is of
> course again a case of lots of pain for little gain ;-)

#milliSeconds has caused me aLittleBitOfPain a dozen times today.�� Delay uses milliseconds and I've come to intrinsically expect to type it all lowercase.�� It only takes 5 seconds to correct, but in accumulation, its annoying. ��

On Tue, Mar 3, 2015 at 9:52 PM, Sven Van Caekenberghe��<sven@stfx.eu>��wrote:

I agree, but the recent #subStrings: to #substrings: forced me to add another package with one method to make Zinc work in Pharo 2, 3 and 4 (after I managed to convince others to make a change to pharo 3 too).

There *is* pain in those external codebases trying to target multiple versions.

For a simple method rename like this we should be able to push the new names into the old releases.

On Tue, Mar 3, 2015 at 9:54 PM, Marcus Denker��<marcus.denker@inria.fr>��wrote:

I said this already: we can not be backward compatible forever. There needs to be a cutoff. For me is is that we support one version back.
We could do 2 versions. But there *has* to be a defined point in the past where we do not care anymore.

You could do "staged" reduction in support.�� Back one version might get general bug fixes. Back two or more versions might only get cleanup method renames.�� Now the idea with pushing method renames back is that its not just about backward support, but about showing people the way forward, and also about reducing friction to make such cleanup changes.

Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use, rather than everyone needing to roll their own?�� Maybe this is even something that Grease etc might reference?

��

I definitely recall feeling "lots of pain" with the subStringXyz ->
substringXyz that we're still dealing with in recent updates (I think I
started that push as a naive newbie), but I'm not sure about the "little
gain" part. It's hard to quantify the negative effect of inconsistency in
the system, or the empowering effect of uniformity. There's the practical
"was /this/ case the milliS or the millis??", as well as the more subtle
effect of a calm, happy feeling users may get from a system in which the
little details have been cared for.

IMNSHO: Fix all these little things now while so many changes are swirling
around the system. The longer we wait, the more mature/widely-used Pharo
gets, the less practical these changes will become

I agree with Sean's sentiment - consistency cannot be underestimated, and its better to take the hit now while the community is smaller. ��

cheers -ben