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
