About squeak image compatibility (3.6/7/8)
goran at krampe.se
goran at krampe.se
Mon Jan 9 10:36:32 UTC 2006
Avi Bryant <avi.bryant at gmail.com> wrote:
> A suggestion that I think I've made in the past is that we explicitly
> acknowledge the forking by not privileging any of the forks with the
> name "Squeak" or the front page of squeak.org. Instead, squeak.org
> could direct people to the fork that is most likely to be useful to
> them, whether that's Squeakland, Tweak, Croquet, Spoon, SqueakLight,
> Traits (what we're now calling 3.9a), Seaside (not really a fork yet
> but could be), or something else. Work to make the basic
> infrastructure of websites, bug trackers, FTP servers, SqueakMap,
> SqueakSource and so on "fork aware" and equally available to any fork
> that has a following. And if you're worried about the negative
> connotations of "fork", call them "distributions" instead...
Distributions is a better name yes. And I am quite comfortable with this
approach - hoping of course that we still have some kind of ambition -
as a community - to maintain a set of core packages that are meant to be
used by all distros.
So such an approach could look like this:
1. At the bottom we have the VM. Hopefully we can keep it canonical :).
2. Then we have multiple distro "kernel" images. As small as possible,
but of course it is up to the distro how "small" it is. The current
"Squeak" distro could be renamed to something else.
3. On top of those kernels we load packages and there is a Set of such
packages that are recognized by the large Squeak community as "core
packages" creating our common base. So the idea is that they hopefully
work on top of all kernels so if you stick to those you could write code
that works in all distros.
4. Then we have the jungle of packages on top. On SM today there is
already a category to mark packages as being available for different
distros (but only two as of now):
If there is broad consent for this "realignment" (embracing the concept
of distributions) I can gladly continue to move SM in that direction.
For example, it could register kernel images and distros in general
(homepage, repos etc).
More information about the Squeak-dev