Anybody want to help us Guides fix a process bug? (was:Re:[Fwd:
Package Loader version filtering ...
danielv at netvision.net.il
Wed Feb 12 20:57:28 UTC 2003
Well, actually, the things you mention is the sort of direction we'd
like to see in the future. Right now, we don't have depedencies, and no
support for a "requires X" tag.
So what I'm looking for is more like a simple fix for the existing
filter in SML that shows you just the packages your image supports (in
it's own simplistic way).
Actually, I've just thought of a better fix that will be applicable as
soon as we have services (we can write services that can act as filters,
and put arbitrarily complex code there).
Goran: the problem is with 3.3, for example, where it simply isn't the
release previous to 3.4. This might happen in the future, too (though I
Colin Putney <cputney at whistler.com> wrote:
> On Wednesday, February 12, 2003, at 10:14 AM, cg at cdegroot.com wrote:
> > Daniel Vainsencher <squeak-dev at lists.squeakfoundation.org> said:
> >> What you want, I think, is a 'requires'/'provides' pair. A Squeak base
> >> release 'provides' some interface version, a package 'requires' some
> >> interface version. I'd decouple this from the published version
> >> number,
> >> because with all the mods we're going to have on the 'outside' with
> >> little change on the 'inside' (just like now - two Squeak versions are
> >> internally the same) they are going to deviate quickly.
> >> Probably you want to match on as much detail as 'requires' provides.
> >> So
> >> with current 3.5 Squeak providing '3.0', a package could require '3',
> >> '3.0', or even '3.0.1' (if there ever would be a 3.0.1 patch release).
> >> If you call this package 'base' or 'core', you'd have
> >> - Squeak 3.5alpha provides 'base-3.0'
> >> - Package foo (most packages, I think), require 'base-3'.
> A slight variation on this, which I think would work even better, would
> be to make "requires" refer to an update number rather than a release.
> So you'd get 'base-5968'.
> Of course, the next step would be to revamp update streams to
> accommodation a package-oriented universe. Off the top of my head, I
> think that would mean update streams for individual packages, and
> streams which include Daniel's "levels of compatibility" data for each
> Colin Putney
More information about the Squeak-dev