[Squeakfoundation]updating to next version after declining alpha

[Daniel Vainsencher]

Have you tried exporting importing when moving from a 3.5 final to a
initial 3.6alpha? it's very improbable that the final changes would
include changes that make your morphs incompatible, compared to
exporting importing across wider version gulfs.

Otherwise, I do sympathize with your claim in principle, but as long as
we don't put absolute limits on what final changes might include (no
do-its, no shape changes, just method definitions, nothing that didn't
get into version n.m+1), I don't see how the problem can be avoided.
Proposals welcome.

Daniel

Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> 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
> changesets.
> 
> > 
> > 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 
> loaded.
> 
> 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 
> 3.5.
> 
> 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.
> 
> Joshua
> 
> > 
> > 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/1.2.5.1i
> > > 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
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation