Revived from the dead [Re: [squeak-dev] [Cuis] Cuis]

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Jan 24 18:50:14 UTC 2010


2010/1/24 Igor Stasenko <siguctua at gmail.com>:
> 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.
>
>

Sure.
Continuous integration is not that easy.
However, I would try to make new developments in the bleeding edge
version for these reasons:
- react early to uncompatible changes
- propose hooks to reduce the level of kernel patching
You can't control everything but it's better to keep an eye opened
rather than discovering unwanted changes lately.
And it's even better if you can bend some developments toward your own
direction.

Nicolas



More information about the Squeak-dev mailing list