Hi Doug and all!

Doug Way <dway at mailcan.com> wrote:
> I just put a new 1.01beta release of the Whisker Browser out on 
> SqueakMap, for those interested.  This fixes a few bugs related to 
> actions on instance variables when using 3.7, among other things.
> 
> But mainly, I wanted to mention the way I'm releasing this on 
> SqueakMap... I think this could be a useful way to do things for some 
> other packages too.
> 
> I'm still planning on adding a few more fixes to this release, so I've 
> named this one 1.01beta, and I've left it unpublished.  I'll probably 
> put up a newer version sometime soon, replacing the .cs.gz file pointed 
> to by 1.01beta.  And then sometime after that, if it looks pretty 
> solid, I'll rename the release version number from 1.01beta to 1.01, 
> and then mark it as published.  (SqueakMap lets you rename unpublished 
> release version numbers.)

In fact, if I am not mistaken - SqueakMap lets you rename the manual
version number *anytime* - regardless of the published/unpublished flag.
But the auto version number can never be changed. :)

>  After that, I won't change anything with 
> that release anymore, I'd just create a new release if I needed to.

Exactemente. :)
 
> This way, since "1.01beta" is unpublished and shows up in the SM loader 
> in parentheses, it's pretty clear that it's a beta release which is not 
> quite finished, but is still available for people to try (if the 
> previous version is completely broken for example).
> 
> This might be a good way for something like the BFAV package releases 
> to be handled.  IMHO it's a bit of a pain to have to go to SqueakSource 
> to get the very latest version of a package like BFAV, if you're not 
> used to using MC on a regular basis.  (Especially if the last stable 
> version on SM is broken by something in the update stream.)  I believe 
> there's a button or something in SqueakSource that lets you publish a 
> new release directly to SqueakMap?  It'd also be nice to have a button 
> to just put out the latest SqueakSource code, overwriting into an 
> unpublished release on SqueakMap.  (Maybe this works already?)
> 
> Perhaps this was the intent behind Goran's published/unpublished scheme 
> anyway, but I thought I'd offer up these details as one way to do 
> things.
>
> - Doug

Thanks Doug - and yes, this is indeed the intention with
published/unpublished. So in short - if a package release is marked
"unpublished" it can't be trusted to not change - hell, it may even get
deleted. The maintainer isn't promising *anything* about it.

But if it is marked as *published* then at least the developer has
promised that the release:

1. Will not be deleted in the future.
2. Will not change. (typically the file referred to in the URL is
immutable)

This means that it can be dependend upon. Because it will *be there* and
will *not change*.

Another simpler usage pattern is that when you have made a new package
release and think it is ready to be put on SM - do it, but don't mark it
as published just yet. Then try installing it, perhaps tell people to
try it out - and if it seems to work ok - *then* you mark it as
published. If some stupid mistake is discovered - either fix it "in
place" (by replacing the file pointed to by the URL with a corrected
file) or just delete the release and get back to hacking on it. :)

This way you avoid "dumb releases" with silly mistakes in them.

> p.s. Actually, it looks like you can rename the version number for a 
> *published* release on SqueakMap, too... which seems like it probably 
> shouldn't be allowed.  Add to Goran's low priority to-do list? ;)

Nah, I believe in "freedom under responsibility". It is just a plain
dumb thing to do - so don't do it. :)

And if you want to have a version number that you can *trust to never
change* - then refer to the auto version number. :)

regards, Göran