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@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@lists.squeakfoundation.org [mailto:squeakfoundation-bounces@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
On Saturday, March 22, 2003, at 06:32 AM, danielv@netvision.net.il wrote:
How about this combination -
- 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.
That sounds pretty good to me... that enables someone else to help out with this instead of it being entirely my responsibility. ;-)
But I think that would work. Most people typically don't need to update from a m.n final to a m.n+1 alpha, but for those who do, the SM package will be there. And yes, assuming we don't allow huge numbers of fixes during beta/gamma phases (which we shouldn't), most of the time there won't be conflicts anyway.
- Doug Way
squeakfoundation@lists.squeakfoundation.org
-
danielv＠netvision.net.il -
Doug Way