Goran  --

I think SMPackageRelease ought to know the name/email of the person in 
charge of that release.  Sometimes people want to do archeology...  

Also, I think it might prove handy for package release to be able to 
list its features.

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.
>
>
>  
>