[Squeakfoundation]updating to next version after declining alpha

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Fri Mar 21 17:39:25 CET 2003

On Fri, Mar 21, 2003 at 09:00:19PM +0300, Daniel Vainsencher wrote:
> Hmm, do you have any ideas on how we can do this? it seems to me that
> two ideas here are in conflict -
> 1. "I should get backported fixes into 3.5 that worked in 3.6, without
> moving into 3.6 while it's alpha"
> 2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all"

Right.  I don't see that there necessarily a conflict, at least 
conceptually; for instance, Debian lets you do these kind of things.
However, you are probably right that there is a conflict once we 
examine things from the point of view of Squeak update streams and

> You can do either one of those manually now, by simply proceeding up
> only one of the upgrade paths, but I don't have ideas on how you can
> have both. 

Hmm, I need to introduce some terminology.  Call "base 3.5/6" the state
of the image right after the version is advanced, but before any further
updates are loaded.  Call "current 3.5/6" the state of the image with
all of the updates currently available in the appropriate update stream 

Most of the time, when backported fixes get added to current 3.5, you'll
be lucky and things won't break if you update with all of the changes
up to current 3.6.  However, sometimes they will, but you should be 
able to notice this by testing.

Backported fixes could be tested by filing in the fix to a current 3.5
and then updating it to current 3.6.  If it breaks, then we could figure
out why, and either fix it so that it would be smooth sailing to 3.6, or
decided that it's not worth the effort.  New 3.6 changesets could be 
tested to ensure that they work with a current 3.6, and a 3.5 updated
to current 3.6.

This would admittedly be more work for those in charge of the update
streams, probably too much  I thought about only allowing updates from 
a final 3.5, so the 3.6 update stream only had to be tested against a 
final 3.5 and a base 3.6, but this wouldn't work if some earlier 3.5 
changeset caused problems that precluded later updating, since that 
changeset couldn't retroactively be removed from the update stream.  I 
guess the best option would be to just not load any final updates to 

Still, I don't like the idea of 3.5 final possibly being a short 
dead-end branch, especially when it is not made clear to users that
this is the case (a newbie would have no way of knowing that loading
updates to 3.5 after the branch to 3.6 might make it impossible to 
later update to 3.6).  At the least, the rollover message could
warn that to accept further 3.5 updates voids the guarantee that
a later update to 3.5 will work fine.

> On another note, some people might ask "why do you keep important stuff
> in your image anyway?"

Because the important stuff consists of morphs.  Where else would I keep them,
and still have them handy to modify?  I haven't had perfect luck in the past
with exporting and re-importing morphs between different versions of Squeak,
and it would be a lot of extra hassle keeping track of all the exported files.


> Daniel
> Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> > I originally posted this to squeak-dev, but it probably should have
> > been sent here.
> > 
> > 
> > ----- Forwarded message from Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> -----
> > 
> > Date: Wed, 19 Mar 2003 21:59:18 -0500
> > From: "Joshua 'Schwa' Gargus" <schwa at cc.gatech.edu>
> > Reply-To: The general-purpose Squeak developers list
> > 	<squeak-dev at lists.squeakfoundation.org>
> > To: Squeak Mailing List <squeak-dev at lists.squeakfoundation.org>
> > Subject: updating to next version after declining alpha
> > User-Agent: Mutt/
> > Delivered-To: mailman-squeak-dev at lists.squeakfoundation.org
> > List-Id: The general-purpose Squeak developers list
> >  <squeak-dev.lists.squeakfoundation.org>
> > List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>,
> > 	<mailto:squeak-dev-request at lists.squeakfoundation.org?subject=unsubscribe>
> > List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-dev>
> > List-Post: <mailto:squeak-dev at lists.squeakfoundation.org>
> > List-Help: <mailto:squeak-dev-request at lists.squeakfoundation.org?subject=help>
> > List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>,
> > 	<mailto:squeak-dev-request at lists.squeakfoundation.org?subject=subscribe>
> > Errors-To: squeak-dev-bounces at lists.squeakfoundation.org
> > 
> > I have a comment about Squeak version releases that may or may not
> > have been discussed already.  My concern relates to beginning a new
> > alpha branch before the previous version is finalized.  This happens
> > every time, and I think that it is unavoidable.  
> > 
> > I currently have a 3.5 beta "living" image where I keep a lot of 
> > important information.  I don't want to advance it to 3.6 alpha 
> > because I can't afford to mess it up.  So, I chose to only receive
> > the final fixes for the 3.5 release.  However, some day 3.6 will
> > be stable enough to switch to.  My problem involves the uncertainty
> > about being able to successfully update from a 3.5 final release 
> > (which may include updates after the choice about whether to go
> > 3.5 or 3.6).  
> > 
> > Can we manage the update streams in such a way that we can be certain
> > that such updates are possible?  In most cases, it probably works fine
> > on its own.  However, I think that it is important for users to be 
> > able to rely on this invariant.
> > 
> > Comments?
> > 
> > Joshua
> > 
> > ----- End forwarded message -----
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation

More information about the Squeakfoundation mailing list