Hi Doug--
Also, I suppose if the goal is to move 3.4 toward a release relatively soon (in the next month or two?) then getting the SM bootstrap into the 3.2 series becomes less urgent.
Why can't we leave 3.2 alone and make 3.4 the venue of SqueakMap's mainstream debut?
Will someone please summarize the rationale for revisiting a "final" release here, and for getting into tertiary version numbers?
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta wrote:
Hi Doug--
Also, I suppose if the goal is to move 3.4 toward a release relatively soon (in the next month or two?) then getting the SM bootstrap into the 3.2 series becomes less urgent.
Why can't we leave 3.2 alone and make 3.4 the venue of SqueakMap'smainstream debut?
Will someone please summarize the rationale for revisiting a "final"release here, and for getting into tertiary version numbers?
I think most of the rationale for revisiting the 3.2 release was based on some discussions before OOPSLA (in other words, before the decision was made to abandon 3.3alpha).
Daniel, Goran, Ned and I had a few email conversations with Scott & SqC about adding some basic support for SqueakMap in 3.2. This seemed like an important goal at the time, because having SM easily accessible to everyone via the update stream would be a big boost to SM usage. We still weren't sure what was going to happen with 3.3alpha, and we hadn't considered leapfrogging 3.3alpha to go to 3.4alpha yet.
Also, the last few Squeak releases (3.0, 3.2) had been about a year apart, and we didn't want to wait around for 3.3alpha to become stable, which probably would have been another long wait.
Now that we're working toward 3.4, and we've decided that it should be finalized relatively soon, I suppose there wasn't a great need to split off 3.2. Oh well. :-) However, there were a lot of 3.2-compatible packages already in place on SqueakMap, so it seemed like SqueakMap should have some sort of debut in the 3.2 world. (I was thinking in my recent message that since we already split off 3.2.1, we might as well add the SqueakMap bootstrap too, but that's not super-important.)
(Scott and/or SqC came up with 3.2.1 version name. But to me it seems like the best name for what it represents, it indicates a minor change to 3.2. It probably wouldn't have been good just to add the updates to 3.2, since 3.2 had already been declared "final" and was out on squeak.org for a couple of months.)
Okay, enough about that... onward with 3.4alpha. :-)
- Doug
Hi Doug--
Now that we're working toward 3.4, and we've decided that it should be finalized relatively soon, I suppose there wasn't a great need to split off 3.2. Oh well. :-) However, there were a lot of 3.2-compatible packages already in place on SqueakMap, so it seemed like SqueakMap should have some sort of debut in the 3.2 world.
As I suggested at this month's OOPSLA Squeak BOF, I think the thing to do is make 3.4 consist of just 3.2final plus SqueakMap. This would seem to have negligible impact on registered packages; I think we could just make confirmation of that part of the testing for 3.4. Then start on 3.5, with all the other changes floating around since the beginning of development on the now-defunct 3.3.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta wrote:
As I suggested at this month's OOPSLA Squeak BOF, I think the thing todo is make 3.4 consist of just 3.2final plus SqueakMap. This would seem to have negligible impact on registered packages; I think we could just make confirmation of that part of the testing for 3.4. Then start on 3.5, with all the other changes floating around since the beginning of development on the now-defunct 3.3.
Not an unreasonable suggestion, but I think it's probably too late to do that at this point, without introducing a lot of confusion.
3.2.1 has already been created (as a fork in the update stream, it doesn't appear to be on the ftp site). And 3.4alpha already has all of the 3.3alpha changes retrofitted into its update stream, plus a few other small changes. So to make 3.4 consist of only 3.2final plus SqueakMap, we'd have to dump almost all of the stuff currently in the 3.4alpha update stream. This would cause confusion for people currently using 3.4alpha, and it may also cause problems for some packages on SqueakMap which are listed as 3.4alpha-compatible and which may depend on some of the updates in 3.4alpha.
Scott/SqC actually split off 3.2.1 before the Guides really got organized, so it wasn't really a Guides-based decision. But I think the current situation is OK anyway.
(I could go either way as to whether your suggestion or the current situation is the better way to handle it. On one hand, Squeak does not normally update its minor version number (e.g. 3.2 to 3.4) based on such a small addition code-wise (SqueakMap), so a tertiary version for this makes some sense. On the other hand, Squeak has never used tertiary version numbering before, so it is a bit weird to introduce it now.)
If we don't like tertiary version numbers for Squeak releases, maybe we could agree to try to avoid them in the future.
John also suggested that we could have just updated 3.2 with SqueakMap and left the version number at 3.2, but I tend to agree with Craig that that would not have been a good idea, because Squeak 3.2 had already been released as "final" and was available on the download page at squeak.org for a couple of months. If we had done this, there would have been confusion as to which version was the real 3.2final. (For example, I think Stephane Ducasse might have used the original 3.2final to put on CD's for his book.)
- Doug
Hi Doug--
FWIW...
3.2.1 has already been created (as a fork in the update stream, it doesn't appear to be on the ftp site). And 3.4alpha already has all of the 3.3alpha changes retrofitted into its update stream, plus a few other small changes. So to make 3.4 consist of only 3.2final plus SqueakMap, we'd have to dump almost all of the stuff currently in the 3.4alpha update stream. This would cause confusion for people currently using 3.4alpha, and it may also cause problems for some packages on SqueakMap which are listed as 3.4alpha-compatible and which may depend on some of the updates in 3.4alpha.
I don't buy that argument, given the nature of "alpha" ("features definitely missing, and possible bugs"). I think people who are willing to use alpha releases should be prepared for stuff like this. (http://netjam.org/smalltalk/versions.html)
(I could go either way as to whether your suggestion or the current situation is the better way to handle it. On one hand, Squeak does not normally update its minor version number (e.g. 3.2 to 3.4) based on such a small addition code-wise (SqueakMap)...
I don't think SqueakMap is "a small addition". But regardless, I don't think the creation of a new minor version should require any particular new-feature-set magnitude. It's far more important to simply make clear that the feature set has changed (and I don't see any great disadvantage to declaring a version dead, especially if it has yet to reach the final release stage). And I don't think tertiary versions ever carry their cognitive weight.
If we don't like tertiary version numbers for Squeak releases, maybe we could agree to try to avoid them in the future.
That has my vote. :)
John also suggested that we could have just updated 3.2 with SqueakMap and left the version number at 3.2, but I tend to agree with Craig that that would not have been a good idea, because Squeak 3.2 had already been released as "final" and was available on the download page at squeak.org for a couple of months. If we had done this, there would have been confusion as to which version was the real 3.2final. (For example, I think Stephane Ducasse might have used the original 3.2final to put on CD's for his book.)
Very well put. :)
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
Well I should wade in and point out a few things that I've noticed over the years.
a) Many users will use 3.xFINAL as the preferred deployment package because they feel 3.x+1Alpha is too experimental for them to risk using because they are not power-squeak users. In fact I still encounter people who are using 2.8 or 3.0 because until recently 3.2 was 3.2gama. Mm tonight I was going to download 3.4alpha to some ones desktop but he pointed out he didn't run alpha or beta software on his machine because it was too risky so I had to promise that 3.4ALPHA wasn't going to hose his machine (a true story).
I'd think one should finalize 3.2 and stuff SM into it mostly because that's a way for people to distribute content/apps/changesets/? in the 3.2. environment. I say finalize, although it's final mostly because there's a few patchs etc from 3.3 (I think?) I'm sure one can of course say this SM is 3.2 or 3.4 or 3.2/3.4 compatible...
Ps zap any thoughts of 3.2.x (tertiary numbers).
On Wednesday, November 20, 2002, at 05:42 PM, Doug Way wrote:
Craig Latta wrote:
Hi Doug--
Also, I suppose if the goal is to move 3.4 toward a release relatively soon (in the next month or two?) then getting the SM bootstrap into the 3.2 series becomes less urgent.
Why can't we leave 3.2 alone and make 3.4 the venue ofSqueakMap's mainstream debut?
Will someone please summarize the rationale for revisiting a"final" release here, and for getting into tertiary version numbers?
....
Now that we're working toward 3.4, and we've decided that it should be finalized relatively soon, I suppose there wasn't a great need to split off 3.2. Oh well. :-) However, there were a lot of 3.2-compatible packages already in place on SqueakMap, so it seemed like SqueakMap should have some sort of debut in the 3.2 world. (I was thinking in my recent message that since we already split off 3.2.1, we might as well add the SqueakMap bootstrap too, but that's not super-important.)
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi John--
a) Many users will use 3.xFINAL as the preferred deployment package because they feel 3.x+1Alpha is too experimental for them to risk using because they are not power-squeak users. In fact I still encounter people who are using 2.8 or 3.0 because until recently 3.2 was 3.2gama. Mm tonight I was going to download 3.4alpha to some ones desktop but he pointed out he didn't run alpha or beta software on his machine because it was too risky so I had to promise that 3.4ALPHA wasn't going to hose his machine (a true story).
So release a 3.4final. :) If we just finish testing SqueakMap, we're done!
I'd think one should finalize 3.2 and stuff SM into it mostly because that's a way for people to distribute content/apps/changesets/? in the 3.2. environment.
I think that's a bad idea. We have a final 3.2 already; it just happens to lack a particular feature (SqueakMap). Why not just put that feature into 3.4, and, after testing it, declare it 3.4final? It doesn't make any sense to me to tamper with 3.2final, because none of its existing features are catastrophically broken.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org/resume Smalltalkers do: [:it | All with: Class, (And love: it)]
On Wednesday, November 20, 2002, at 11:11 PM, Craig Latta wrote:
So release a 3.4final. :) If we just finish testing SqueakMap, we're done!
I'd think one should finalize 3.2 and stuff SM into it mostly because that's a way for people to distribute content/apps/changesets/? in the 3.2. environment.
I think that's a bad idea. We have a final 3.2 already; it just happens to lack a particular feature (SqueakMap). Why not just put that feature into 3.4, and, after testing it, declare it 3.4final? It doesn't make any sense to me to tamper with 3.2final, because none of its existing features are catastrophically broken.
Mmm I'm a bit slow on the uptake tonight. so let me summarize?
3.4 is 3.2 + 3.3 critical changes + (SM & fixes)
Finalize that, then proceed to 3.5alpha
Yes?
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com wrote:
On Wednesday, November 20, 2002, at 11:11 PM, Craig Latta wrote:
So release a 3.4final. :) If we just finish testing SqueakMap, we're done!
I'd think one should finalize 3.2 and stuff SM into it mostly because that's a way for people to distribute content/apps/changesets/? in the 3.2. environment.
I think that's a bad idea. We have a final 3.2 already; it just happens to lack a particular feature (SqueakMap). Why not just put that feature into 3.4, and, after testing it, declare it 3.4final? It doesn't make any sense to me to tamper with 3.2final, because none of its existing features are catastrophically broken.
Mmm I'm a bit slow on the uptake tonight. so let me summarize?
3.4 is 3.2 + 3.3 critical changes + (SM & fixes)
Finalize that, then proceed to 3.5alpha
Yes?
Sounds pretty fine to me. Just as long as we give 3.4alpha a time to "rest" before finalizing. Otherwise we will not have a chance to clean up any mess we might have introduced...
regards, Göran
PS. Yesterday I moved SqueakMap to 1.04 according to instructions from Scott. This means it is now "extension clean" with regard to 3.2.1 and 3.4alpha. It also means that it will protest if being installed in 3.2.
goran.hultgren@bluefish.se wrote:
John M McIntosh johnmci@smalltalkconsulting.com wrote:
Mmm I'm a bit slow on the uptake tonight. so let me summarize?
3.4 is 3.2 + 3.3 critical changes + (SM & fixes)
Finalize that, then proceed to 3.5alpha
Yes?
Sounds pretty fine to me. Just as long as we give 3.4alpha a time to "rest" before finalizing. Otherwise we will not have a chance to clean up any mess we might have introduced...
This sounds roughly right to me.
However, in an earlier message, Daniel mentioned something about also having a few simple applications (Celeste, IRC, PWS, etc.) removed from the image for 3.4 once they are converted to packages on SqueakMap. Do we still want to do this? It might be nice to have in 3.4 as a demonstration of how the image is going to be broken down, but I guess it depends on how simple we want the 3.4 release to be, and how soon we want to release it.
There seems to be general agreement that we want to release 3.4 relatively soon. Does this mean in 2 weeks? 5 weeks? 8 weeks?
Scott, since you are helping us with the 3.4 release this time around, feel free to chime in with your thoughts as well.
Also, I was going to solicit people on the squeak-dev list to suggest any important fixes which have been submitted in the last 6 months but not incorporated, so that we could harvest a handful of important items for 3.4. (If I do this, I will do it tomorrow.) Or should this wait until 3.5alpha?
PS. Yesterday I moved SqueakMap to 1.04 according to instructions from Scott. This means it is now "extension clean" with regard to 3.2.1 and 3.4alpha. It also means that it will protest if being installed in 3.2.
Ah, that's good. :)
- Doug
At 7:38 PM -0500 11/21/02, Doug Way wrote:
Scott, since you are helping us with the 3.4 release this time around, feel free to chime in with your thoughts as well.
I suggest we consider 3.4 "code complete" right now and move it into beta this weekend.
I anticipate a short beta cycle, since there are very few known bugs.
In mid-December I anticipate the first 3.4gamma *image* build -- this will be code-identical to the final 3.4beta. This -- with its help windows and its sample projects -- will evolve into the actual release image.
Historically, it takes several gamma cycles to iron out all the kinks. However, unless anyone wishes to undertake it, I don't think that a makeover of the existing sample projects should be on our agenda. Indeed, they have received only minimal attention since 3.0 nearly two years ago.
Barring misadventure, I still anticipate that we could build and release the final Squeak 3.4 image by the end of December.
Known bugs to be addressed in beta:
* There is the http issue that Ned has recently raised an alarm about (or is this now fixed by something Michael has sent out?)
* Ned has pointed out that there are quite a few defects in MacFileDirectory -- I'm not certain how many of them have always been present and how many are fresh in 3.4a because of code ported from 3.3a that never got much of a workout there and may be buggy. Perhaps Ned can circulate a list of the problems he has noticed.
Are there other known bugs in 3.4a? (Bugs that already existed in 3.2 shouldn't really count ;-)
Cheers,
-- Scott
Hi Gang,
Boy, do I agree with John on this one. I had hoped that 3.4 would be a stable, finalized version of 3.2-4956, plus a few cleaned up details and SM, and said so in a recent message to Scott Wallace on the squeak-dev list. Unfortunately, someone took issue with the tone of that message which got lost in the noise.
I have SWT, 2.8, and 3.2-4956, plus two VMs (3.2.8b9 and 3.2.2) that John and Marcel were kind enough to help me with. I'm sticking with this combo until the next stable release is finalized before I even begin to even think about upgrading. The Squeak power-users can enjoy themselves with pre-alpha, alpha, and beta code. John's buddy (client?) is absolutely right about the risk of using alpha and/or beta software.
Cheers, Roger.....
On Wednesday, Nov 20, 2002, at 23:29 America/Denver, John M McIntosh wrote:
Well I should wade in and point out a few things that I've noticed over the years.
a) Many users will use 3.xFINAL as the preferred deployment package because they feel 3.x+1Alpha is too experimental for them to risk using because they are not power-squeak users. In fact I still encounter people who are using 2.8 or 3.0 because until recently 3.2 was 3.2gama. Mm tonight I was going to download 3.4alpha to some ones desktop but he pointed out he didn't run alpha or beta software on his machine because it was too risky so I had to promise that 3.4ALPHA wasn't going to hose his machine (a true story).
I'd think one should finalize 3.2 and stuff SM into it mostly because that's a way for people to distribute content/apps/changesets/? in the 3.2. environment. I say finalize, although it's final mostly because there's a few patchs etc from 3.3 (I think?) I'm sure one can of course say this SM is 3.2 or 3.4 or 3.2/3.4 compatible...
Ps zap any thoughts of 3.2.x (tertiary numbers).
On Wednesday, November 20, 2002, at 05:42 PM, Doug Way wrote:
Craig Latta wrote:
Hi Doug--
Also, I suppose if the goal is to move 3.4 toward a release relatively soon (in the next month or two?) then getting the SM bootstrap into the 3.2 series becomes less urgent.
Why can't we leave 3.2 alone and make 3.4 the venue ofSqueakMap's mainstream debut?
Will someone please summarize the rationale for revisiting a"final" release here, and for getting into tertiary version numbers?
....
Now that we're working toward 3.4, and we've decided that it should be finalized relatively soon, I suppose there wasn't a great need to split off 3.2. Oh well. :-) However, there were a lot of 3.2-compatible packages already in place on SqueakMap, so it seemed like SqueakMap should have some sort of debut in the 3.2 world. (I was thinking in my recent message that since we already split off 3.2.1, we might as well add the SqueakMap bootstrap too, but that's not super-important.)
--
==== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================= ====
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org
-
Craig Latta -
Doug Way -
goran.hultgren＠bluefish.se -
John M McIntosh -
Roger Vossler -
Scott Wallace