>
> Take the changes of Sets: they are faster and can include nil. Also,
> IdentitySet scale far better. What do you suggest ?
> Have only one change every two months ?
> Tell Levente "no no, we cannot accept your contribution, it's too  
> fast" ?
>
> Nicolas

In this case you would treat Sets as a load-able module managed  
outside of the image, publish version 1.0.

Levente makes his changes available as version 1.0.1, and they are  
immediately available to all forks.

When the next monthly build comes around it loads the latest version  
of Sets, and runs tests. If it breaks then some patches are required  
somewhere either before or after it loads. These patches are a "slice"  
of integration code that apply to this image only.

Along comes Juan, wanting to load Sets, and he can see the  
implementation, before and after, and the integration code. All he has  
to do is come up with his own integration code.

-
If the Api changes significantly, then you have to be more creative,  
and there are a number of options.

1. Load both api's simultaneously, in parallel with poor mans  
namespaces, or real namespaces if you have them.
2. Use facades to provide a common face to two api's, and a switch  
between them.
3. Refactor all users of FIleDirectory into a recognizable protocol  
(method category, or tagged), that can be replaced in one simple slice.

Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/ac447ec0/attachment.htm