[Squeakfoundation]updating to next version after declining alpha

[danielv at netvision.net.il]

How about this combination -
1. By default we don't put in "final updates" that will cause
compatibility problems.
2. When we put out alpha, someone can create a small SM package that
changes versions specifically from m.n to m.n+1. Installing it will
allow people to continue updating, but warn that there's a small chance
the updates will be incompatible, so save your image first.

Should solve 95% of these issues.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Doug,
> 
> Three notes on this. First of all, the rollover message has some rather
> scary implications. It implies that you _will_ receive "test pilot" updates
> when you advance your system to alpha vs. that you _may_ receive final fixes
> if you choose the other way. I would suggest to change this towards
> something indicating that if you go into a final branch you're really
> entering a dead end versus going onto alpha you _may_ update your system to
> the next version at a point of your choosing. Note the subtle difference ;-)
> 
> Secondly, it should be pretty straightforward to flip from a final branch
> over to the next alpha - after all, all that's needed is setting the system
> version right. A simple thing that could be done is to install a "next
> version identifier" which contains the next future version a system could be
> advanced to. If you choose to, then all that happens is that you are set to
> the next update branch. This would allow people to stay with (for example)
> 3.5 until 3.6 is finalized, then switch to 3.6 (at which point the next
> future version is 3.6alpha) and update through everything (during which
> there may be other future versions such as beta and gamma). When you receive
> one of these advance messages choosing the "dead end" would just install the
> next future (perhaps this is a better way of distinguishing the streams - a
> "live" and a "dead" one; with the dead one only containing retrofitted stuff
> from the live one).
> 
> Also, concerning feeding back fixes into "final" branches I think that a
> Very Useful rule of thumb should be that any fix going into final should be
> resiliant to updating through the point at which it appears in the next
> future version (testing this is almost trivial). For 95% of the fixes this
> will be the case anyway. For the remaining 5% an explicit warning in the
> update that "installing this update/fix will remove your ability to advance
> to X.Y" might be appropriate. If the above mechanism would exist, the update
> could simply reset the next future version.
> 
> BTW, this entire thing is an issue I am quite interested in myself. With the
> rapid releases you are aiming at it's a real pain in the neck to jump
> versions. I was going to switch Croquet to 3.4 but now you're talking about
> finalizing 3.5 already so I'm going to wait for this. Unless, of course,
> there's going to be a 3.6 a month after that in which case I might wait for
> it ;-)
> 
> Cheers,
>   - Andreas
> 
> 
> 
> > -----Original Message-----
> > From: squeakfoundation-bounces at lists.squeakfoundation.org 
> > [mailto:squeakfoundation-bounces at lists.squeakfoundation.org] 
> > On Behalf Of Doug Way
> > Sent: Saturday, March 22, 2003 2:51 AM
> > To: Discussing the Squeak Foundation
> > Subject: Re: [Squeakfoundation]updating to next version after 
> > declining alpha
> > 
> > 
> > 
> > On Friday, March 21, 2003, at 05:39 PM, Joshua 'Schwa' Gargus wrote:
> > 
> > > 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.
> > 
> > I could improve the rollover message next time to include that.  (I 
> > assume you meant "a later update to 3.6 will work fine" above.)
> > 
> > Actually, the current message sort of implies that anyway, it 
> > says that 
> > you will only be allowed to receive final fixes for the 3.5 
> > release, if 
> > you choose not to advance to the next alpha.  Here's the 
> > 3.5beta split 
> > message:
> > 
> > "Do you wish to advance to version 3.6alpha?
> > [Yes] Your system will be marked as 3.6alpha, and you will
> > subsequently receive ''test pilot'' updates for 3.6.
> > [No] Your system will be marked as 3.5beta, allowing you
> > to receive only final fixes for the 3.5 release."
> > 
> > I could add it to something like "Your system will be marked as 
> > 3.5beta, allowing you to receive only final fixes for the 3.5 
> > release.  
> > You won't have a further opportunity to update to 3.6alpha."
> > 
> > Or, technically it should be "You may not have a further 
> > opportunity..." because in some cases, if no changes go into the beta 
> > for whatever reason, we can add another opportunity to advance when 
> > going to gamma.  This happened with 3.4beta->3.4gamma/3.5alpha.
> > 
> > Anyway, I'm not going to spend a lot of time thinking about whether 
> > there's a better solution to this, because I can't imagine one right 
> > now that's not a lot of effort. :-)  Perhaps sometime in the 
> > future if 
> > we have a generic uninstall capability.
> > 
> > - Doug Way
> > 
> > _______________________________________________
> > 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