I see no reason why it should not be possible to break an existing API.
However, to make this possible, it should be the responsibility of the
breaker to:
1) Provide backward compatibility patch (that will eventually later be
deprecated)
   I would prefer it to be an add-on package (like
CompatibilityWith39), if moving methods across packages were not so
messy...
2) Provide guidelines for easing transition (where? a wiki? and/or a
ReleaseNotes.txt distributed with the image?)
   Even better if some automated rewrite rules are also provided.
3) and of course, provide a good rationale in preamble to any such change

Nicolas

2009/7/24 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> I am currently using the Cuis, which doesn't having a 'SmalltalkImage
>> current' refactoring..
>
> Ah, one of my favorite rant subjects. First, it's not a refactoring;
> refactorings leave the public interfaces intact (I really hate it when
> people call random rewrites "refactoring" code). Secondly I'm still 100%
> behind what I wrote here about Smalltalk vs. "SamlltalkImage current":
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/118175.html
>
> I'm very glad to hear that Cuis doesn't use SmalltalkImage.
>
>> Now, Smalltalk == SmalltalkImage current and everyone is happy:
>>  - dictionary lives in separate ivar,
>>  - fat & boring housekeeping stuff lives in SmalltalkImage instance.
>>
>> What you think?
>
> I think it's a definitive improvement to the current situation.
>
> Cheers,
>  - Andreas
>
>
>
>