Avi Bryant <avi at beta4.com> wrote:
> 
> On Fri, 25 Oct 2002 danielv at netvision.net.il wrote:
> 
> > Hi.
> > I've worked a bit with the new version lying in the background. When I
> > started, I have one manager called * SM-Loader. Now I have two identical
> > ones. How come?
> 
> Hmm, not sure what you mean.  Elaborate?
I simply have two entries in the same PackagePanel, both called '*
SM-Loader', with identical state. This is no catastrophe, but probably
shouldn't happen.

> Yes, that could work - SMLoaderInfo could keep a version counter, and
> #externalName could be overriden to append the version number to the
> package name.  Then you just have to say
> 
> SMLoaderInfo default nextVersion
> 
> just before you file out.  You could even use the normal fileOut button,
> except that it won't zip it for you...
> 
> That's actually kinda cute, cause then if you want to revert/update to a
> previous version, you can do
> 
> SMLoaderInfo default
>   version: 42;
>   manager fileIn.
Actually, I'd want higher level operator than #version: 
What I'd want is a #makeRelease message that increments and files out. 
An #abandonTo: message that changes version, removes the module, and
files in the old one. This is a dangerous message, because it loses
everything you've done.
A #changeTo: message is like revert, except it is not dangerous - it
only works if the current state of the module is identical to some
release. 
A #compareTo: shows me the differences between the current version and
some other.

Then for packages managed using DVS, I could use SM to download the new
version (not install), and do compareTo: the new one using DVS.

As a maintainer of such a package, I would be able to easily review my
changes (to make sure I hadn't left some self halt in there), make
internal releases ready (separate from posting the to the net).

The next step comes when we have old versions of cards in SqueakMap, and
then anyone can compareTo/changeTo any released version...

One thing that would be nice is if the package knew whenever it's code
was changed, it could automatically increment the version only when it's
needed, and also, this would allow the package to handle someone editing
an old version (forking).

Do you think this is good functionality for the base PackageInfo? or
does it clash somehow?

> Avi

Daniel