From: Alan Knight
[mailto:[hidden email]]
StoreForGlorp actually adds an #Obsolete blessing level for
precisely this purpose, and the package that generates the view at http://www.cincomsmalltalk.com/publicStore
will ignore things for which the most recent (or maybe it's any) version has
this blessing. That could (should) be integrated into base Store, and other things
could make use of it as well.
Steven Kelly wrote:
How does that work if there are two branches, and one is marked
#Obsolete? That's one of the current weaknesses of the VW Store tools –
versions are perceived as a single linear sequence in most of them. The Graph
Versions tool can show the branchings, but even that does not show the merges.
It would not work - and that doesn't really make any sense with the semantics
it's using for Obsolete. It indicates that the package or bundle as a whole is
obsolete and should be filtered out of the list.
The field is probably in the wrong place then. You're marking a particular
blessing of a particular version in a particular branch of a particular pundle.
What you really want to mark is the pundle itself. Of course Store doesn't
currently allow that, so your approach might be a useful hack for now. I
wouldn't suggest integrating it into base Store, though. There are quite enough
ad hoc solutions in that code base already…
Another approach is to consider re-blessing each version of the app
with #Obsolete. We do something like that to old versions in our own Store, and
I've done it to packages in the public Store: if we later notice a major
mistake in a version or versions, re-bless them as #Broken. Store could hide
all versions whose most recent blessing is #Obsolete, and if no versions
remained for a given pundle, hide the whole pundle.
Cheers,
Steve
--
Alan Knight [|], Cincom Smalltalk Development
"The Static Typing Philosophy: Make it fast. Make it right.
Make it run." - Niall Ross
Locked
