Ned Konz <ned at bike-nomad.com> wrote:
> The problem with this is that you may be removing extension methods 
> that replaced existing methods in the system.
> 
> What you probably want to do is to revert them, but we don't have 
> enough context to tell which version you'd want to revert them to. If 
> you could tell that a certain version came from a given package or 
> package version, that would be easier.
How about an intermediate solution? Envy uses it and IMHO it works quite
well.

Suppose you have a package A which defines a method #someMethod on a
class SomeClass loaded and versioned in the image. If you then load
package B which also defines #someMethod in SomeClass, Envy detects the
conflict, overwrites the conflicting method with the new one, and marks
package A as a so called scratch edition which does not include the
conflicting method any more.

If you then unload package B, package A still remains a scratch edition.
In order to revert it back to its previous state you have to reload
package A again.

So, basically Envy does not solve the problem. You have to solve it
yourself. But Envy shows you where the problems are. You can easily
query all scratch editions.

All you would need is to maintain a state in the image which packages
are still versions, i.e. were not yet changed since the last load and
which are scratch edtions. (There is a third state called an open
edition which means that currently work is going on there.)

I realize that this is not the correct solution for the problem.
However, perhaps it would serve as a workaround until the holy grail of
unloading packages is found. I know that it has been working for me for
several years now.

To Avi, Colin, et al.: By the way, I am *really* excited about
Monticello! Thank you very much for doing this. Having configuration and
version management is just so important. And I really like that you seem
to have decided for a Smalltalk only solution, i.e. no CVS, etc. I am
looking forward to using it. Many thanks!

Bernhard