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.