This is kind of what Seaside's Grease platform is starting to provide,
so obviously I think it's a good approach. Grease documents "standard"
APIs that we expect on all platforms via unit tests. Each platform is
then required to ensure the tests pass, either by fixing their base
image, or by adding extensions to their Grease package.

If Seaside doesn't work and all the Grease tests pass, either we need
to change Seaside, or add a test to Grease. We've now begun using
Grease as the basis for Pier, Magritte, and MC2, so the hope is that
it might become generally useful to other projects that want to write
code that runs across platforms (we're not just talking Squeak forks
here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
lofty goal, though, and we're taking a pragmatic, step by step
approach.

Julian

On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Folks,
>
> Package developers want their work to run on various Squeak versions and
> variants, without needing rewrite. Same for app developers.
>
> Base image builders want to be free of the need to provide backwards
> compatibility.
>
> This is what I suggest: A package assumes it can use a set of apis of the
> Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions
> should be made explicit, in the form of tests. So, for example, for
> collections, some package developer might require the "Common Collection API
> tests" to pass. Then, if his package fails to run, let's say in Cuis, he
> would run the tests for the apis he needs. If some test fails, he could say
> "Cuis developers, you're not supporting api XXX", end expect them to fix the
> issue. But if no test fails, he needs to either modify his code so it
> doesn't use not-standarized apis, or he could negotiate with (all) base
> image developers the addition of a new api or use case to the test suite and
> the base images.
>
> Building these suites is quite some work, mostly to be done by package
> developers. But it can easily point out responsibilities and duties. It
> frees package developers of needing to have a deep knowledge of various base
> images. And it frees base image developers from needing to know details
> about an unbounded set of external packages. Besides, it puts popular
> packages that everybody wants to support on equal footing with less-known
> packages. It also lets base image developers say "we support Common APIs
> xxx, yyy, zzz, etc.".
>
> All what I say about base images could also apply to packages that offer
> services to other packages: There could also be test suites to specify their
> services, and allow users to switch versions of the packages they use
> knowing what to expect.
>
> What do you think?
>
> Cheers,
> Juan Vuletich
>
>