> But perhaps a package owner may want to try setting up an 
> update stream for a package sometime soon.

There's an active one for Balloon3D which I am using to post interim fixes
between full package updates.

> Update streams may be overkill for some packages,
> but for others it might make sense.

I find them quite convenient for most purposes inbetween "larger versions".
E.g., creating a new package version can be quite a bit of work and it's
nice if you can post a fix for a small change just using an update stream.
Even if noone else uses it, it can make your own life in managing the
package a little easier, in particular in the absence of good (integrated)
tool support for other kinds of shared repositories.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Doug Way
> Sent: Wednesday, August 20, 2003 8:11 PM
> To: The general-purpose Squeak developers list
> Subject: Re: 3.6 Full release testing (was Re: [BUG]? Upgrade 
> to full image script behavior)
> 
> 
> goran.krampe at bluefish.se wrote:
> 
> >Michael Rueger <michael at squeakland.org> wrote:
> >  
> >
> >>Richard A. O'Keefe wrote:
> >>
> >>    
> >>
> >>>- Can I be confident that updates to the Base image will have been
> >>>  *tested* with all the packages in the Full image, and 
> that updates
> >>>  will check for the presence of packages they are 
> incompatible with,
> >>>  so that I will be warned about and allowed to cancel an 
> update that
> >>>  might break the Full image?
> >>>      
> >>>
> >>No, no, and not really doable in practice. Even MS with 
> their gazillions 
> >>of testers fails to achieve this.
> >>    
> >>
> >
> >You should be confident that the updates at least "load" in a Full
> >image. I think Doug or whoever is in charge of the updatestream will
> >ensure that at least. And perhaps he may also run the available Unit
> >tests for the Base image that Marcus maintains. And perhaps even
> >existing unit tests for the packages in Full (are there any 
> yet for the
> >famous 9?).
> >
> >But no manual testing will be performed - no time for that. 
> Again, Doug
> >can tell you how much of the above he does today before 
> pushing it out.
> >  
> >
> 
> Currently, I do make sure that any about-to-be-published updates 
> successfully load into a Basic image, of course.  Now that we are 
> talking about "supporting" Full images following the same 
> update stream, 
> I will plan on also making sure the about-to-be-published updates 
> successfully load into a Full image too, at least.  (A Full image in 
> this case will be a Basic image with the "upgrade to full" 
> script loaded 
> a few minutes prior.)
> 
> (The other thing I do test for right now is any conflicts between a 
> given update and more recent changes in the image and the 
> other updates 
> in the batch.  The ConflictChecker does this, and it has caught a few 
> update conflicts over the last few months, which I haved 
> fixed on the spot.)
> 
> I'm not currently running any Unit tests, although that's not a bad 
> idea.  Some of the famous 9 Full packages do have corresponding Unit 
> test packages, btw.  (Scamper, Celeste, Games, at least.)  I 
> could give 
> this a try.  Although we've also talked about having a server 
> out there 
> somewhere running Unit tests on a regular basis.
> 
> Right now I'm working on making my life easier by creating a 
> little tool 
> which collects a list of potential updates in a window (added 
> from the 
> BFAV), and then lets me number them as a group, load/check 
> conflicts on 
> all of them at once, broadcast them all at once, and send out the 
> [update - xxxx] messages.  Right now I do these steps manually.  This 
> tool is partly done.
> 
> >>>- Will packages that are not part of the Base image also have some
> >>>  kind of update stream, or will they only be replaced in toto on
> >>>  SqueakMap?
> >>>      
> >>>
> >>That is very much up in the air right now, part of the 
> reason for the 
> >>many messages that have been flying around.
> >>    
> >>
> >
> >Yes, this is in the air. I assume you mean the official 
> Squeak packages
> >(currently the famous 9) and not *all* packages on SM. I also assume
> >that we will decide on a common strategy for these packages. But we
> >haven't done so yet. Andreas has made a hack available for setting up
> >updatestreams per packages that works with SM1. SM2 will include some
> >fields for this.
> >
> >But perhaps we will instead choose to use Monticello for 
> these packages
> >and not "stream of a bunch of ChangeSets" at all.
> >
> 
> Yep. :-)  I'm not going to be spending any mental effort on this 
> particular issue anytime soon, there's enough other stuff to 
> work on.  
> But perhaps a package owner may want to try setting up an 
> update stream 
> for a package sometime soon. (probably after SM2 is out)  
> Update streams 
> may be overkill for some packages, but for others it might make sense.
> 
> >>>- Is there _anything_ I can do to keep a Full Squeak current, or do
> >>>  I just jump from official release to official release?
> >>>
> >>>To be perfectly honest, I have hitherto *preferred* "wait 
> for the next
> >>>stable release" to "keep quite current", but I have been 
> feeling a bit
> >>>guilty about that, because it's one of the main reasons 
> why I haven't
> >>>done any bug fix testing.  The fact that a bug fix seems 
> to work in my
> >>>image does NOT imply that it works in a fully patched 
> image, so I've
> >>>felt that any bug testing I did would have been pointless.
> >>>      
> >>>
> >>So in practice not much is going to change for you then? ;-)
> >>Seriously, I've also preferred to not update while I'm in 
> the middle of 
> >>some development and the squeakland plugin image is also 
> getting new 
> >>releases twice a year at the most.
> >>As I said, the update stream is called alpha for a reason.
> >>    
> >>
> >
> >If you want to keep up with alpha/beta/gamma streams then 
> just go ahead.
> >The stream is there for a reason. But it is currently not 
> only used as a
> >general update mecanism for a stable release.
> >  
> >
> 
> You might not want to do large projects on top of a Full alpha image, 
> but it's not hard at all to just keep a Full alpha image (3.6) around 
> and update it periodically, in addition to a stable release image 
> (3.5).  If you see a bug in your stable image, you can check your 
> updated alpha image to see if the bug is also there, and then 
> submit a 
> bug report/fix, and thus participate in the bug 
> reporting/fixing process.
> 
> - Doug
> 
> 
>