2010/3/11 keith <keith_hodges at yahoo.co.uk>:
>> 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
>
Well, the public API did not change.
But the changes were deeper than Set. They contaminate the whole
hierarchy down to MethodDictionary.
They also concern changes of identityHash.
So it is not solvable with an External package.
That's a typical case where continuous integration helps.
I'm convinced such work must be redone from scratch in each fork...
... or maybe re-buidling the whole image like gst. But it's not yet an
option in Squeak.
Nicolas