<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Take the changes of Sets: they are faster and can include nil. Also,<br>IdentitySet scale far better. What do you suggest ?<br>Have only one change every two months ?<br>Tell Levente "no no, we cannot accept your contribution, it's too fast" ?<br><br>Nicolas<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div></div><div>In this case you would treat Sets as a load-able module managed outside of the image, publish version 1.0.</div><div><br></div><div>Levente makes his changes available as version 1.0.1, and they are immediately available to all forks.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-</div><div>If the Api changes significantly, then you have to be more creative, and there are a number of options. </div><div><br></div><div>1. Load both api's simultaneously, in parallel with poor mans namespaces, or real namespaces if you have them.</div><div>2. Use facades to provide a common face to two api's, and a switch between them. </div><div>3. Refactor all users of FIleDirectory into a recognizable protocol (method category, or tagged), that can be replaced in one simple slice.</div><div><br></div><div>Keith</div></body></html>