> On 13 May 2015, at 15:38, Julien Delplanque <[email protected]> wrote: > > So, I throw the fork on github and provide a compatibility package on > smalltalkhub?
It is not a demand. Just a suggestion. You can do whatever you want and nobody can impose you how to handle your code :) Esteban > > I wanted to improve the lib, but I don't own it and there is no "pull > request" system on smalltalk hub. > I don't want to bother the owner of the repository with changes I want to do. > He probably has others things to do. > > Also, I don't use and don't have interest in squeak and gemstone (for the > moment) so providing compatibility with pharo 2-3-4, squeak and gemstone... I > will not do that. > > Finally, I already made some improvements in some objects of the model part > what should I do? > > Regards, > > Julien > > On 13/05/15 15:03, Stephan Eggermont wrote: >> On 13/05/15 13:44, Esteban Lorenzano wrote: >>> honestly, the more and more the time passes the less and less we are >>> compatible… and this will increase will time. >>> if you want to keep compatibility you will have to provide compatibility >>> abstractions and packages (in the same way Seaside uses Grease, etc.) >>> >>> now… In this particular case I didn’t see any contributor from outside >>> Pharo community… so is just an “abstract reflection”, not a reality… I >>> would wait until some one in the Squeak community decides to use it and >>> then it creates the compatibility layer (adding layers are usually a bad >>> thing… specially when they are not necessary). >> >> In this case forking is a very bad idea. >> >> It has been maintained by Paul for squeak, pharo and gemstone. >> We know that not every library will be up to date as soon as a new >> version of Pharo is released. Please dump the fork and make a >> compatibility package. >> >> Stephan >> >> >> > >
