2010/1/24 keith <keith_hodges at yahoo.co.uk>:
>
> What's your goal ?
> Develop an application ?
> Develop a cross-fork module/package/library ?
>
> Both: Develop an application using cross-fork packages.
> However the way things are going, its all I can manage to do the
> application, keeping all the balls in the air is a problem.
>

Developing an application means freezing a set of dependencies.
If you're not freezing them, then you not developing an application,
you just toying.

Because, you'll never know that might be broken, when you update
dependencies to the latest,
so you are always doing it at own risk (and don't blame the devs about
breaking things - its absurd), because despite what package maintainer
says, there are always a chance that with even little and minimal
update, your application could stop working normally.
This is what we calling 'moving target'.
Sure thing, if package maintainer tries to preserve compatibility,
then in 99% cases everything ok, but if he not - then its up to you
to manually update the application to conform with newer version of
package. And always will.

The only class of updates, which can be acceptable in such ecosystem
is bug fixes. But if you need to move forward, like introduce new &
better stuff, or remove obsolete cruft, you inevitably will meet
compatibility problems.

Honestly, what kind of automation you can invent here to migrate your
application from using package version A,
to package version B , which potentially, can be completely rewritten
from scratch?
You doomed to either stay with version A, or do a lot of manual work
migrating to version B and no magic tool will help you with that.

About cross-fork package development.

Each package having an environment-agnostic behavior , and environment
dependent.
The goal of developer is to identify these parts and connect them nicely.
But this is gone too far. It is now about defining and enforcing a
good practices in package development to avoid cross-dialect pitfalls.
How many packages we has built with cross-compatibility in mind?
How many packages having all globals declared in a single place, not
scattered among code?
And what automated tools can solve the problems, when your package
code using 'SmalltalkImage current' instead of 'Smalltalk'?


> If the later (RIO), then use what every other cross-fork do,
> compatibility layers (Grease...).
>
> Never heard of it, I have been out of the loop for a while.
> Is grease a package? why didn't whoever developed Grease, add to LPF which
> is already doing this? Or perhaps we just need to add Grease to LPF.
>
> Otherwise, concentrate on the fork you have chosen and let people port
> if they are interested.
>
> I haven't chosen a fork, I was going to use pharo, but found it somewhat
> reliant on OB which I dont get along with.
> So discovering that I didnt actually have a fork that I found interesting I
> cam back here to see if cuis would do the trick.
> this looks like it might be too much work.
> So I will probably just stay where I am, earn some money and employ someone
> else to port things later on (you never know).
> In the meantime the community looses the maintainence of any of the
> cross-fork packages I already provide.
> Keith
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.