Daniel Vainsencher <danielv at netvision.net.il> wrote:
> 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...

Yes (I know about those) I was thinking along the same route but...
Hmmm.
And I agree, immutability of SMPackageRelease is good but - do we want
to enforce it?

For example, today you can delete SMPackages. That would turn into a
no-no. And if you make any little mistake in the SMPackageRelease then
you would need to make a new one... I was actually thinking of simply
informing the user of SM that they really should be immutable, at least
regarding the downloadable.

So let's see. I agree that maintainer is something that can change over
time - that should be in SMPackageRelease (no need to copy stuff or
anything - an SMPackageRelease will be created from the start anyway).
What is left?

description, author, categories (since SMPackage is a SMPersonalObject)

- I didn't want to "see" package releases when browsing categories. But
I think I am changing my mind, there will be tons of situations where a
release needs other categories than another release. But this will
present us with interesting UI problems. What are we listing, packages
or releases? When an old release is in category X (but not the current
release) - should we list that package in that category? An easy "way
out" would be to say that, no we only list releases - but that would
really make the SM UIs cluttered in no time. But UI problems can be
solved.

- description and author should stay in SMPackage, according to my
previous argument.

Ok, so it turned out as a compromise. :-) I still want to have them as
two different classes (because they are different things and basic OO
says that, hey, keep them different then), but I moved "maintainer" and
"categories" over to SMPackageRelease.

One such big difference is that SMPackage is "personal" - it has
password, registrant etc. An SMPackageRelease is also owned by an
SMPackage, but an SMPackage is owned by the map.

Good. I have made up my mind then about this little part. So this is my
final design (apart from other stuff I haven't decided yet):

SMObject #('id' 'map' 'created' 'updated' 'name' 'summary' 'url'
'annotations')
	SMCategory #('mandatory' 'subCategories' 'parent' 'objects')
	SMCategorizableObject #('categories')
		SMPackageRelease #('maintainer' 'automaticVersion' 'version' 'note'
'downloadUrl')
 		SMPersonalObject #('registrator' 'password' 'newPassword')
			SMPackage #('description' 'author' 'releases')

Note the new base class "SMCategorizableObject" (spelling?). Renamed
"comment" to "note"..

regards, Göran