On 13/05/15 15:38, Julien Delplanque wrote:
So, I throw the fork on github and provide a compatibility package on smalltalkhub?
Yes. Forking is ok if it is difficult to maintain compatibility, and that is definitely not the case here. Paul has made improvements to the code a few months back, so it doesn't look like an abandoned code base. The Pharo support for git(hub) is not yet at the level where it is easy to support forking smalltalkhub repos on github and merging back. Soon, I hope.
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.
Don't need to. This is open source. You can commit in the repo. Mailing lists are not as nice as pull requests for collaboration, but work well enough.
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.
That is ok. The people using squeak, older pharo and gemstone will fix their own problems. The only thing needed is separating between the things you do in a generic package, and those you do in the pharo (4/5) specific one.
Finally, I already made some improvements in some objects of the model part what should I do?
Avoid making people do the work twice. This code is likely to be used in production by some people, so needs to keep working in old versions too. Stephan