Levente Uzonyi wrote:
> There's no guarantee that old code works even if all previously removed 
> methods are added again. For example if a subclass of Set in an external 
> package has it's own version of #findElementOrNil: or #fullCheck, it may 
> have no effect, since it will have no senders in Set. I think that the 
> only way is to update external packages and use them. So far the only 
> package I fixed is DynamicBindings, the fixed version is available here:
> http://squeaksource.com/KomHttpServer/DynamicBindings-ul.12.mcz .

I think we're all in violent agreement here. The introduction of such 
changes has to be decided in the concrete context. From my point of 
view, due to the importance of Seaside we have no choice but to provide 
backwards compatibility for DynamicBindings - the failure mode is too 
obscure to risk having people run into it.

>>  platformName
>>    "After Squeak version 3.6, #platformName was moved to SmalltalkImage "
>>     ^ ((Smalltalk classNamed: 'SmalltalkImage')
>>         ifNil: [^ Smalltalk platformName]) current platformName
>>
> 
> What about this?
> SystemDictionary >> orSmalltalkImage
> 
>     ^(self at: #SmalltalkImage ifAbsent: [ ^self ]) current
> 
> Which would let us write: Smalltalk orSmalltalkImage platformName.

Eeek! :-) Juan has the right solution for this problem in Cuis:

SmalltalkImage class>>current
	^Smalltalk

and then leave the methods in Smalltalk which is the only sensible place 
anyway. (I'd really like to move things back at some point)

> As I noted above, having these methods in the image do not ensure 100% 
> backwards compatibility with external packages.
> Five years may be too much, noone will remember in 2015 that some 
> methods/classes can be removed from the image.
> Sometimes it's easier to fix the external packages (like the 
> DynamicBindings case, where the fix is fully backwards compatible).
> I think we should produce a migration guide, like the Seaside developers:
> http://www.seaside.st/documentation/migration . This could also include 
> a list of deprecated features (methods/classes).

I agree with all of these comments as well (and I think David does, 
too). The main issue is: Sometimes we need backwards compatibility. 
DynamicBindings is a situation where I strongly feel it's worth it 
because it's so widely used in all sorts of old and new Seaside versions.

Cheers,
   - Andreas