I would love to have that!
I have the impression that the only way there is to have tests (for  
what is really possible to tests).
We could really have a task force focussing on key packages and  
working so that they are sharable and that
when there is a change we know it, identify it, and can control the  
evolution of the package.

Stef

On 23 juil. 07, at 01:36, Andreas Raab wrote:

> Hi -
>
> I just spent some in 3.10 and while I felt that there wasn't much  
> that personally excited me about it, there were still plenty of  
> fixes that were interesting enough for me so that I'll have to  
> spend significant time to integrate them into Croquet. And if you  
> look at what has recently gone into Croquet [1] I'm pretty sure  
> you'll find the same the other way around (for example the font  
> caching fixes come directly from Croquet). After looking over 3.10  
> it again occurred to me how splintered the larger Squeak community  
> is when it comes to some of the core parts of its software.
>
> I think that at some point we'll have to admit that using  
> individual images is a reality that we simply need to accept and  
> deal with it accordingly. And one of the key parts is to understand  
> how to share code across these different images.
>
> The trouble with code sharing is that the most important packages  
> are still completely bound to particular images. There is no  
> "Collection" package that I can load in from 3.4 through 3.10 and  
> expect it to work. There is no common "Numbers", no "Streams", no  
> "Files", Sockets, Sound, Exceptions, anything package. While there  
> are plenty of application-level packages that support a range of  
> images, there is almost nothing at the core of Squeak that can be  
> used across different images.
>
> And I'm curious if there is interest in changing this. At least on  
> the level where it's fairly non-controversial (e.g., I wouldn't be  
> planning on starting with metclasses, m17n, or compiler) it could  
> be a pretty interesting for various projects to be able to have a  
> common code base, with decent tests to ensure it runs on all the  
> the supported image versions etc. So that, for example, if there is  
> an improvement to Dictionary you can benefit from it implicitly  
> regardless of whether you are using a particular image or not.
>
> In short, what I'm looking for is something like a set of "standard  
> packages" which are supported beyond the particular image they  
> apply to. In thinking about this, two questions came to my mind:
>
> 1. Is this technically feasible? I'm not certain about this given  
> how tightly various of the core packages depend on the particular  
> idiosyncrasies of particular images. But it'd be interesting to  
> find out whether (for example) we could make up a "standard Number  
> package" that can easily be installed and supported in various  
> versions.
>
> 2. Perhaps more importantly, is there any interest in doing  
> something like this? Since it would most certainly require serious  
> work it could only be done if other people feel the same like I do  
> and are willing to put in some time and effort. If people are happy  
> with where they are today (which is quite possible) then this is a  
> no-win situation.
>
> *If* something like this works, it may be one step out of the image  
> lock-in that we currently endure. It could also help focusing  
> various (currently completely disjoint) parts of the community on  
> help improving a shared base.
>
> Comments welcome.
>
> Cheers,
>   - Andreas
>
> [1] https://lists.duke.edu/sympa/arc/croquet-dev/2007-05/msg00035.html
>
>