SqueakMap going forward

Daniel Vainsencher danielv at netvision.net.il
Mon Nov 25 23:05:10 UTC 2002


Sounds fine to me. Another option to consider would be to simply store
everything in the release - in effect, make package releases immutable.
This loses no information (which seems like a much harder to regret
choice than the alternatives), and require fewer decision both in the
design and in the usage later ("Should I replace the maintainer now that
I'm making this one release, or is it to early to wipe his memory
forever?" - > "this release is mine, the previous 300 remain untouched
whatever I do").

Also, if we want configurations to be able to target old releases, it
seems nice to be able to provide the complete, precise metadata under
which they were released.

So a package would simply bind together the history of releases of the
same package, or provide a facade for it.

This is sort of like class histories in GemStone...

Just my 2 agorot <ching!>
Daniel

goran.hultgren at bluefish.se wrote:
> Hi all!
> 
> Ok, first a simple one: What extra, new, changed categories do we need?
> Note that I have added "Package type" with subs but didn't think it
> needed to be mandatory. Perhaps it does? Also in another thread, perhaps
> we could add a few licenses - like the MIT license for example.
> 
> Now a teeny bit trickier one:
> 
> 		SMObject #('id' 'map' 'created' 'updated' 'name' 'summary' 'url'
> 'annotations')
> 			SMCategory #('mandatory' 'subCategories' 'parent' 'objects')
> 			SMPackageRelease #('automaticVersion' 'version' 'comment'
> 'downloadUrl')
> 			SMPersonalObject #('registrator' 'password' 'newPassword'
> 'categories')
> 				SMCard #('currentVersion' 'description' 'downloadUrl' 'author'
> 'maintainer' 'versionComment' 'releases')
> 
> The above is my not-yet-ready refactoring of the hierarchy on SM.
> SMPersonalObject is a new intermediate abstract class for those object
> we actually register with password etc. This made SMCategory cleaner of
> course and also made SMObject a better fit as base class for the new
> SMPackageRelease.
> 
> - Given that name (SMPackageRelease), shouldn't we still rename SMCard
> to SMPackage? I think so. The library metaphor wasn't that bleeding
> good.
> 
> - As you see above SMCard is still the object that represents the
> package itself. And it has "releases" - an OrderedCollection of
> SMPackageRelease. The SMPackageRelease has taken over version
> (currentVersion) and comment (versionComment) from SMCard - but I
> haven't removed them in SMCard yet for clarity here.
> 
> Now... what else should go into SMPackageRelease? Let me give you my
> thoughts:
> 
> description: Nah. Of course it can change with time, but shouldn't we
> then instead change the SMCard? I think it can get confusing with
> multiple versions of the description of package X. So keep it updated in
> SMCard and add version specifics in the SMPackageRelease>>comment.
> 
> author: Should be the same over time, yes? It is mostly meant as a field
> for the original author/authors if the package has been handed over to
> someone else. Credit where credit due and all that.
> 
> maintainer: Hmmm. Could of course change over time but isn't it always
> the *current* maintainer that is interesting to know? I think so. Let
> the other fellows be forgotten because that is probably what they want
> if they have handed the package over to someone else. :-)
> 
> So, if you all agree with me then the above will turn out like this
> (cleaned up):
> 
> 	SMObject #('id' 'map' 'created' 'updated' 'name' 'summary' 'url'
> 'annotations')
> 		SMCategory #('mandatory' 'subCategories' 'parent' 'objects')
> 		SMPackageRelease #('automaticVersion' 'version' 'comment'
> 'downloadUrl')
> 		SMPersonalObject #('registrator' 'password' 'newPassword'
> 'categories')
> 			SMPackage #('description' 'author' 'maintainer' 'releases')
> 
> Other things of interest:
> 
> - Only SMPersonalObjects can be categorised. Is this correct? I think so
> - different SMPackageReleases having different categories would also
> confuse utterly I think.
> - All SMObjects will be able to have annotations. This is the general
> Post-It (tm) mechanism I am planning to add to handle bugreports,
> comments, feedback etc. May also be useful perhaps in regard to FIX/ENH
> feedback on packages.
> - automaticVersion is meant to use Stephen Pairs version numbering
> package. We will still have both a UUID and a manually edited version
> too.
> 
> regards, Göran
> 
> PS. I aim for the above in the 1.1 release of SM. This will give us the
> ability to add composite packages called "load scripts" that can handle
> explicit dependencies. It will also give us the ability to register
> "load scripts" that build images from specific package releases. After
> we have this we can start thinking about managing dependencies more
> intelligently - there is a plan for that too, but given the above we can
> get pretty far using just some nifty packaging.



More information about the Squeak-dev mailing list