Avi Bryant avi@beta4.com wrote:
On Wed, 23 Oct 2002 goran.hultgren@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