Avi Bryant <avi at beta4.com> wrote:
> On Wed, 23 Oct 2002 goran.hultgren at bluefish.se wrote:
> > Personally I think this could be really useful and when/if we decide to
> > add support for individual package update streams in SqueakMap (which I
> > think we should ASAP)
> 
> Well, I'm not so interested in package update streams, since they're
> pretty much unnecessary if you use DVS instead - I find it much more
> reliable to have DVS figure out the differences between the current
> version loaded into an image and whatever the newest version is, than to
> depend on the developer having produced that patch by hand.

But... Hmmm. So how would/could we get the "stretchability" I am after
then?
Your proposal with version numbers is ok, but that would require a new
full "release" of the package and some people like to work with updates
I think. And also like to choose their own version numbering scheme...

And how would we let people contribute fixes and enhancements? I was
thinking of a sort of "incoming" queue for each package which the
maintainer easily could load/review/reject/integrate from.

Perhaps we could have a combination of the approaches:

1. For those using DVS and less frequent releases that are full and
don't use update streams we could add the 1-6 level classification as an
attribute of the version. (this would still let people use whatever
version numbering scheme they like, hmmm - have to take a look at
Stephens code for that would be a shame if it got wasted)

2. For those who like update streams we can have the same classification
per update changeset and let SqueakMap do the "max" calculation of a
sequence as I described etc.

How does this sound? SqueakMap should try to accommodate all variants -
that is the idea (within limits of course).

> But that only works for code packaged with DVS, of course.

Right.

> Avi

regards, Göran