[Squeak 4.0] RC3 is out
Locked
12
12
 
|
People of Squeak,
The RC3 distribution of Squeak 4.0 is now available at: http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz http://ftp.squeak.org/4.0alpha/rc3/ Please chip in, test it out, and reply to this thread if you see any problems. Classes of problems I'd consider blockers: - Broken VM - Corrupt file - Things to do with the image that potentially block relicensing If all is well, I will go ahead and roll the 4.0 directory structure with all of the other files one usually finds there. Thanks! -- Casey Ransberger |
|
|
Ah, I should have made a statement about what's changed since RC2.
- Newer Windows VM (3.11.8) - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) This should make things a bit more convenient for folks intent on doing the closure bootstrap. The reason I removed SparklePlugin.bundle: it had some symlinks to stuff in the author's local directories (instead of the correct system directories) that were breaking my build process. I took John's advice and simply removed the bundle. I also fired up the VM to do a sanity check and make sure it still worked. Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger <[hidden email]> wrote: > People of Squeak, > > The RC3 distribution of Squeak 4.0 is now available at: > > http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz > http://ftp.squeak.org/4.0alpha/rc3/ > > Please chip in, test it out, and reply to this thread if you see any > problems. Classes of problems I'd consider blockers: > > - Broken VM > - Corrupt file > - Things to do with the image that potentially block relicensing > > If all is well, I will go ahead and roll the 4.0 directory structure > with all of the other files one usually finds there. > > Thanks! > > -- > Casey Ransberger > -- Casey Ransberger |
|
|
On 13 March 2010 20:28, Casey Ransberger <[hidden email]> wrote:
Ah, I should have made a statement about what's changed since RC2. Loads fine here on OS X (10.5.8). TestRunner runs 2254 test, gets 1 failure, 2 errors. Is this expected? It's a bit of shock to see what bare Squeak looks like, but I guess that's not a blocker :-). |
|
|
Not sure about the test failures. I am hesitant to take time to fix
them and ship another RC; remember, 4.0 needs to work only well enough to salvage. What matters is the relicense and entrance into the SFC. I am not somewhere where I can access Squeak right now. Which tests are failing? On Sat, Mar 13, 2010 at 1:29 PM, Michael Davies <[hidden email]> wrote: > On 13 March 2010 20:28, Casey Ransberger <[hidden email]> wrote: >> >> Ah, I should have made a statement about what's changed since RC2. >> >> - Newer Windows VM (3.11.8) >> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had >> issues) >> > > Loads fine here on OS X (10.5.8). > TestRunner runs 2254 test, gets 1 failure, 2 errors. Is this expected? > > It's a bit of shock to see what bare Squeak looks like, but I guess that's > not a blocker :-). > > > > -- Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Casey Ransberger
(moved the thread from vm-dev back to squeak-dev)
The welcome screen. If you scroll down, all of the information about 3.10 is still there. As far as after release goes: Yeah. Once this thing ships, if anything at all needs to change, we should call it Squeak 4.0.1 or something. I'm hoping that won't need to happen though. It's basically the same as 3.10. Same basic stuff as the last release. On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: > > Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. > And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. > > There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. > > And once you release, you never want to change a zipped file without changing the version. People may depend on it. > A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. > > Ken G. Brown > > At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>Here's the plan: >> >>When I hear these bits are good, I'm going to cut a new directory for >>4.0. It's contents will looks just like what's in the 3.10 directory, >>with the above files swapped in. The reason why you're seeing those >>files, and in particular why it doesn't make sense, is that you're >>seeing them out of context. The reason why you aren't seeing the other >>files and directories that generally accompany them is: the other >>files don't need to change for the 4.0 release. I will in effect be >>copying the entire 3.10 directory to 4.0, and then remove/replace the >>files that correspond to what's in the final release candidate. >> >>The reason I'm scripting everything is, if there's a last minute >>change to for example, the license text, I don't want to have to go to >>all the trouble to copy and zip everything manually; it's time >>consuming and error prone. I'm set up now to take a change to e.g., >>the version of the VM, or something in the image, type 'make' and then >>build and package the whole multiplatform distribution in a minimum of >>steps. >> >>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>the Unix VM was packaged separately from the image, sources, and >>changes files. I didn't see anything about 4.0 which warranted >>changing this policy. >> >>My goal with this release was to get to a ship-able artifact as >>quickly as possible while tolerating last minute changes. I very >>nearly refused to update the Mac and Windows VMs in the zip files as >>well, since these are really orthogonal to the mission of Squeak 4.0, >>but I had some extra time so I did it anyway. >> >>In short, it will make more sense when these files are in their final >>locations on the ftp server. >> >>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>> >>> Good work. >>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>> >>> Might I suggest some clear thought on naming conventions and directory organization? >>> >>> For example I see: >>> ftp://ftp.squeak.org/4.0alpha/rc3/ >>> Squeak4.0-basic.zip >>> Squeak4.0-mac.zip >>> Squeak4.0-win32.zip >>> >>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>> >>> I always try to think - write once, read many. >>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>> >>> Ken G. Brown >>> >>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>Ah, I should have made a statement about what's changed since RC2. >>>> >>>> - Newer Windows VM (3.11.8) >>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>> >>>>This should make things a bit more convenient for folks intent on >>>>doing the closure bootstrap. >> >> >>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>stuff in the author's local directories (instead of the correct system >>>>directories) that were breaking my build process. I took John's advice >>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>check and make sure it still worked. >>>> >>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>> >>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>><[hidden email]> wrote: >>>>> People of Squeak, >>>>> >>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>> >>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>> >>>>> Please chip in, test it out, and reply to this thread if you see any >>>>> problems. Classes of problems I'd consider blockers: >>>>> >>>>> - Broken VM >>>>> - Corrupt file >>>>> - Things to do with the image that potentially block relicensing >>>>> >>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>> with all of the other files one usually finds there. >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Casey Ransberger >>>>> >>>> >>>> >>>> >>>>-- >>>>Casey Ransberger >>> >>> >> >> >> >>-- >>Casey Ransberger > > -- Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/
image that would most likely be good to get in the 4.0. Ken G. Brown At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >(moved the thread from vm-dev back to squeak-dev) > >The welcome screen. If you scroll down, all of the information about >3.10 is still there. > >As far as after release goes: Yeah. Once this thing ships, if anything >at all needs to change, we should call it Squeak 4.0.1 or something. >I'm hoping that won't need to happen though. It's basically the same >as 3.10. Same basic stuff as the last release. > >On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >> >> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >> >> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >> >> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >> >> Ken G. Brown >> >> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>Here's the plan: >>> >>>When I hear these bits are good, I'm going to cut a new directory for >>>4.0. It's contents will looks just like what's in the 3.10 directory, >>>with the above files swapped in. The reason why you're seeing those >>>files, and in particular why it doesn't make sense, is that you're >>>seeing them out of context. The reason why you aren't seeing the other >>>files and directories that generally accompany them is: the other >>>files don't need to change for the 4.0 release. I will in effect be >>>copying the entire 3.10 directory to 4.0, and then remove/replace the >>>files that correspond to what's in the final release candidate. >>> >>>The reason I'm scripting everything is, if there's a last minute >>>change to for example, the license text, I don't want to have to go to >>>all the trouble to copy and zip everything manually; it's time >>>consuming and error prone. I'm set up now to take a change to e.g., >>>the version of the VM, or something in the image, type 'make' and then >>>build and package the whole multiplatform distribution in a minimum of >>>steps. >>> >>>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>the Unix VM was packaged separately from the image, sources, and >>>changes files. I didn't see anything about 4.0 which warranted >>>changing this policy. >>> >>>My goal with this release was to get to a ship-able artifact as >>>quickly as possible while tolerating last minute changes. I very >>>nearly refused to update the Mac and Windows VMs in the zip files as >>>well, since these are really orthogonal to the mission of Squeak 4.0, >>>but I had some extra time so I did it anyway. >>> >>>In short, it will make more sense when these files are in their final >>>locations on the ftp server. >>> >>>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>> >>>> Good work. >>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>> >>>> Might I suggest some clear thought on naming conventions and directory organization? >>>> >>>> For example I see: >>>> ftp://ftp.squeak.org/4.0alpha/rc3/ > >>> Squeak4.0-basic.zip >>>> Squeak4.0-mac.zip >>>> Squeak4.0-win32.zip >>>> >>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>> >>>> I always try to think - write once, read many. >>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>> >>>> Ken G. Brown >>>> >>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>Ah, I should have made a statement about what's changed since RC2. >>>>> >>>>> - Newer Windows VM (3.11.8) >>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>> >>>>>This should make things a bit more convenient for folks intent on >>>>>doing the closure bootstrap. >>> >> >>>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>stuff in the author's local directories (instead of the correct system >>>>>directories) that were breaking my build process. I took John's advice >>>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>>check and make sure it still worked. >>>>> >>>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>> >>>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>><[hidden email]> wrote: >>>>>> People of Squeak, >>>>>> >>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>> >>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>> >>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>> problems. Classes of problems I'd consider blockers: >>>>>> >>>>>> - Broken VM >>>>>> - Corrupt file >>>>>> - Things to do with the image that potentially block relicensing >>>>>> >>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>> with all of the other files one usually finds there. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Casey Ransberger >>>> >>>> >>> >>> >>> >>>-- >>>Casey Ransberger >> >> > > > >-- >Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
On Sat, 13 Mar 2010, Ken G. Brown wrote:
> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ > image that would most likely be good to get in the 4.0. > > Ken G. Brown Seems like you don't get what 4.0 is about. Those fixes should go to the Trunk. If they are really important and are not integrated already, then please copy the links to the bug reports here. Thanks. Levente > > > At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >> (moved the thread from vm-dev back to squeak-dev) >> >> The welcome screen. If you scroll down, all of the information about >> 3.10 is still there. >> >> As far as after release goes: Yeah. Once this thing ships, if anything >> at all needs to change, we should call it Squeak 4.0.1 or something. >> I'm hoping that won't need to happen though. It's basically the same >> as 3.10. Same basic stuff as the last release. >> >> On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >>> >>> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >>> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >>> >>> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >>> >>> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >>> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >>> >>> Ken G. Brown >>> >>> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>> Here's the plan: >>>> >>>> When I hear these bits are good, I'm going to cut a new directory for >>>> 4.0. It's contents will looks just like what's in the 3.10 directory, >>>> with the above files swapped in. The reason why you're seeing those >>>> files, and in particular why it doesn't make sense, is that you're >>>> seeing them out of context. The reason why you aren't seeing the other >>>> files and directories that generally accompany them is: the other >>>> files don't need to change for the 4.0 release. I will in effect be >>>> copying the entire 3.10 directory to 4.0, and then remove/replace the >>>> files that correspond to what's in the final release candidate. >>>> >>>> The reason I'm scripting everything is, if there's a last minute >>>> change to for example, the license text, I don't want to have to go to >>>> all the trouble to copy and zip everything manually; it's time >>>> consuming and error prone. I'm set up now to take a change to e.g., >>>> the version of the VM, or something in the image, type 'make' and then >>>> build and package the whole multiplatform distribution in a minimum of >>>> steps. >>>> >>>> The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>> the Unix VM was packaged separately from the image, sources, and >>>> changes files. I didn't see anything about 4.0 which warranted >>>> changing this policy. >>>> >>>> My goal with this release was to get to a ship-able artifact as >>>> quickly as possible while tolerating last minute changes. I very >>>> nearly refused to update the Mac and Windows VMs in the zip files as >>>> well, since these are really orthogonal to the mission of Squeak 4.0, >>>> but I had some extra time so I did it anyway. >>>> >>>> In short, it will make more sense when these files are in their final >>>> locations on the ftp server. >>>> >>>> On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>>> >>>>> Good work. >>>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>>> >>>>> Might I suggest some clear thought on naming conventions and directory organization? >>>>> >>>>> For example I see: >>>>> ftp://ftp.squeak.org/4.0alpha/rc3/ >>>>> Squeak4.0-basic.zip >>>>> Squeak4.0-mac.zip >>>>> Squeak4.0-win32.zip >>>>> >>>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>>> >>>>> I always try to think - write once, read many. >>>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>>> >>>>> Ken G. Brown >>>>> >>>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>> Ah, I should have made a statement about what's changed since RC2. >>>>>> >>>>>> - Newer Windows VM (3.11.8) >>>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>>> >>>>>> This should make things a bit more convenient for folks intent on >>>>>> doing the closure bootstrap. >>>>>> >>>>>> The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>> stuff in the author's local directories (instead of the correct system >>>>>> directories) that were breaking my build process. I took John's advice >>>>>> and simply removed the bundle. I also fired up the VM to do a sanity >>>>>> check and make sure it still worked. >>>>>> >>>>>> Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>>> >>>>>> On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>>> <[hidden email]> wrote: >>>>>>> People of Squeak, >>>>>>> >>>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>>> >>>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>>> >>>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>>> problems. Classes of problems I'd consider blockers: >>>>>>> >>>>>>> - Broken VM >>>>>>> - Corrupt file >>>>>>> - Things to do with the image that potentially block relicensing >>>>>>> >>>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>>> with all of the other files one usually finds there. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Casey Ransberger >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Casey Ransberger >>> >>> >> >> >> >> -- >> Casey Ransberger > > > |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Casey Ransberger
Further:
And I don't see any sense in rushing to meet some arbitrary deadline. Do the right thing in the right way. Keith says: >I know that you dont expect anyone to actually use 4.0 for real work, however we did have a list of 17 fixes that we used as a basis for building stuff on top of Squeak3.10.2 with LPF, and this image was called Squeak3.10.2-build. > >Out of those 17 fixes one is particularly essential, > >it is http://bugs.squeak.org/view.php?id=6426 > >I would also add 6086, 6466, 6980, 7272, 7308, and 7313 > There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ image that would most likely be good to get in the 4.0. Ken G. Brown At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >(moved the thread from vm-dev back to squeak-dev) > >The welcome screen. If you scroll down, all of the information about >3.10 is still there. > >As far as after release goes: Yeah. Once this thing ships, if anything >at all needs to change, we should call it Squeak 4.0.1 or something. >I'm hoping that won't need to happen though. It's basically the same >as 3.10. Same basic stuff as the last release. > >On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >> >> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >> >> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >> >> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >> >> Ken G. Brown >> >> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>Here's the plan: >>> >>>When I hear these bits are good, I'm going to cut a new directory for >>>4.0. It's contents will looks just like what's in the 3.10 directory, >>>with the above files swapped in. The reason why you're seeing those >>>files, and in particular why it doesn't make sense, is that you're >>>seeing them out of context. The reason why you aren't seeing the other >>>files and directories that generally accompany them is: the other >>>files don't need to change for the 4.0 release. I will in effect be >>>copying the entire 3.10 directory to 4.0, and then remove/replace the >>>files that correspond to what's in the final release candidate. >>> >>>The reason I'm scripting everything is, if there's a last minute >>>change to for example, the license text, I don't want to have to go to >>>all the trouble to copy and zip everything manually; it's time >>>consuming and error prone. I'm set up now to take a change to e.g., >>>the version of the VM, or something in the image, type 'make' and then >>>build and package the whole multiplatform distribution in a minimum of >>>steps. >>> >>>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>the Unix VM was packaged separately from the image, sources, and >>>changes files. I didn't see anything about 4.0 which warranted >>>changing this policy. >>> >>>My goal with this release was to get to a ship-able artifact as >>>quickly as possible while tolerating last minute changes. I very >>>nearly refused to update the Mac and Windows VMs in the zip files as >>>well, since these are really orthogonal to the mission of Squeak 4.0, >>>but I had some extra time so I did it anyway. >>> >>>In short, it will make more sense when these files are in their final >>>locations on the ftp server. >>> >>>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>> >>>> Good work. >>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>> >>>> Might I suggest some clear thought on naming conventions and directory organization? >>>> >>>> For example I see: >>>> ftp://ftp.squeak.org/4.0alpha/rc3/ > >>> Squeak4.0-basic.zip >>>> Squeak4.0-mac.zip >>>> Squeak4.0-win32.zip >>>> >>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>> >>>> I always try to think - write once, read many. >>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>> >>>> Ken G. Brown >>>> >>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>Ah, I should have made a statement about what's changed since RC2. >>>>> >>>>> - Newer Windows VM (3.11.8) >>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>> >>>>>This should make things a bit more convenient for folks intent on >>>>>doing the closure bootstrap. >>> >> >>>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>stuff in the author's local directories (instead of the correct system >>>>>directories) that were breaking my build process. I took John's advice >>>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>>check and make sure it still worked. >>>>> >>>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>> >>>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>><[hidden email]> wrote: >>>>>> People of Squeak, >>>>>> >>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>> >>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>> >>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>> problems. Classes of problems I'd consider blockers: >>>>>> >>>>>> - Broken VM >>>>>> - Corrupt file >>>>>> - Things to do with the image that potentially block relicensing >>>>>> >>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>> with all of the other files one usually finds there. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Casey Ransberger >>>> >>>> >>> >>> >>> >>>-- >>>Casey Ransberger >> >> > > > >-- >Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Casey Ransberger
Keith, Ken:
It pains me to say this, but 4.0 was code frozen as soon as the license was at the top of the sources file and the cruft was out of the object memory. The only purpose of the release is relicensing, and I'm blocking all scope beyond that. Especially two days before we're planning on calling it shipped. I'm really sorry guys. Normally I wouldn't turn down a bug fix, but this is not a regular release; it's neither feature nor quality driven. I'm guessing you guys aren't going to bother with integrating these fixes in Trunk. If that's the case, why not use them to showcase the Bob development process? Start with 4.0 and deploy the fixes in from Mantis? Could be a really good opportunity to get people exposed to, interested in, and ultimately rallied behind your development process. On Sat, Mar 13, 2010 at 6:51 PM, Ken G. Brown <[hidden email]> wrote: > There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ > image that would most likely be good to get in the 4.0. > > Ken G. Brown > > > At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>(moved the thread from vm-dev back to squeak-dev) >> >>The welcome screen. If you scroll down, all of the information about >>3.10 is still there. >> >>As far as after release goes: Yeah. Once this thing ships, if anything >>at all needs to change, we should call it Squeak 4.0.1 or something. >>I'm hoping that won't need to happen though. It's basically the same >>as 3.10. Same basic stuff as the last release. >> >>On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >>> >>> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >>> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >>> >>> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >>> >>> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >>> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >>> >>> Ken G. Brown >>> >>> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>Here's the plan: >>>> >>>>When I hear these bits are good, I'm going to cut a new directory for >>>>4.0. It's contents will looks just like what's in the 3.10 directory, >>>>with the above files swapped in. The reason why you're seeing those >>>>files, and in particular why it doesn't make sense, is that you're >>>>seeing them out of context. The reason why you aren't seeing the other >>>>files and directories that generally accompany them is: the other >>>>files don't need to change for the 4.0 release. I will in effect be >>>>copying the entire 3.10 directory to 4.0, and then remove/replace the >>>>files that correspond to what's in the final release candidate. >>>> >>>>The reason I'm scripting everything is, if there's a last minute >>>>change to for example, the license text, I don't want to have to go to >>>>all the trouble to copy and zip everything manually; it's time >>>>consuming and error prone. I'm set up now to take a change to e.g., >>>>the version of the VM, or something in the image, type 'make' and then >>>>build and package the whole multiplatform distribution in a minimum of >>>>steps. >>>> >>>>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>>the Unix VM was packaged separately from the image, sources, and >>>>changes files. I didn't see anything about 4.0 which warranted >>>>changing this policy. >>>> >>>>My goal with this release was to get to a ship-able artifact as >>>>quickly as possible while tolerating last minute changes. I very >>>>nearly refused to update the Mac and Windows VMs in the zip files as >>>>well, since these are really orthogonal to the mission of Squeak 4.0, >>>>but I had some extra time so I did it anyway. >>>> >>>>In short, it will make more sense when these files are in their final >>>>locations on the ftp server. >>>> >>>>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>>> >>>>> Good work. >>>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>>> >>>>> Might I suggest some clear thought on naming conventions and directory organization? >>>>> >>>>> For example I see: >>>>> ftp://ftp.squeak.org/4.0alpha/rc3/ >> >>> Squeak4.0-basic.zip >>>>> Squeak4.0-mac.zip >>>>> Squeak4.0-win32.zip >>>>> >>>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>>> >>>>> I always try to think - write once, read many. >>>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>>> >>>>> Ken G. Brown >>>>> >>>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>>Ah, I should have made a statement about what's changed since RC2. >>>>>> >>>>>> - Newer Windows VM (3.11.8) >>>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>>> >>>>>>This should make things a bit more convenient for folks intent on >>>>>>doing the closure bootstrap. >>>> >> >>>>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>>stuff in the author's local directories (instead of the correct system >>>>>>directories) that were breaking my build process. I took John's advice >>>>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>>>check and make sure it still worked. >>>>>> >>>>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>>> >>>>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>>><[hidden email]> wrote: >>>>>>> People of Squeak, >>>>>>> >>>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>>> >>>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>>> >>>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>>> problems. Classes of problems I'd consider blockers: >>>>>>> >>>>>>> - Broken VM >>>>>>> - Corrupt file >>>>>>> - Things to do with the image that potentially block relicensing >>>>>>> >>>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>>> with all of the other files one usually finds there. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Casey Ransberger >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Casey Ransberger >>>>> >>>>> >>>> >>>> >>>> >>>>-- >>>>Casey Ransberger >>> >>> >> >> >> >>-- >>Casey Ransberger > > > -- Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
That was the showcase.
It seems incredible to me that anyone would even consider rushing a major release showcase snapshot milestone that will exist forever, without putting some due care and attention to it. Ken G. Brown At 7:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >Keith, Ken: > >It pains me to say this, but 4.0 was code frozen as soon as the >license was at the top of the sources file and the cruft was out of >the object memory. The only purpose of the release is relicensing, and >I'm blocking all scope beyond that. Especially two days before we're >planning on calling it shipped. > >I'm really sorry guys. Normally I wouldn't turn down a bug fix, but >this is not a regular release; it's neither feature nor quality >driven. > >I'm guessing you guys aren't going to bother with integrating these >fixes in Trunk. If that's the case, why not use them to showcase the >Bob development process? Start with 4.0 and deploy the fixes in from >Mantis? Could be a really good opportunity to get people exposed to, >interested in, and ultimately rallied behind your development process. > >On Sat, Mar 13, 2010 at 6:51 PM, Ken G. Brown <[hidden email]> wrote: >> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ >> image that would most likely be good to get in the 4.0. >> >> Ken G. Brown >> >> >> At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>(moved the thread from vm-dev back to squeak-dev) >>> >>>The welcome screen. If you scroll down, all of the information about >>>3.10 is still there. >>> >>>As far as after release goes: Yeah. Once this thing ships, if anything >>>at all needs to change, we should call it Squeak 4.0.1 or something. >>>I'm hoping that won't need to happen though. It's basically the same >>>as 3.10. Same basic stuff as the last release. >>> >>>On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >>>> >>>> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >>>> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >>>> >>>> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >>>> >>>> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >>>> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >>>> >>>> Ken G. Brown >>>> >>>> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>Here's the plan: >>>>> >>>>>When I hear these bits are good, I'm going to cut a new directory for >>>>>4.0. It's contents will looks just like what's in the 3.10 directory, >>>>>with the above files swapped in. The reason why you're seeing those >>>>>files, and in particular why it doesn't make sense, is that you're >>>>>seeing them out of context. The reason why you aren't seeing the other >>>>>files and directories that generally accompany them is: the other >>>>>files don't need to change for the 4.0 release. I will in effect be >>>>>copying the entire 3.10 directory to 4.0, and then remove/replace the >>>>>files that correspond to what's in the final release candidate. >>>>> >>>>>The reason I'm scripting everything is, if there's a last minute >>>>>change to for example, the license text, I don't want to have to go to >>>>>all the trouble to copy and zip everything manually; it's time >>>>>consuming and error prone. I'm set up now to take a change to e.g., > >>>>the version of the VM, or something in the image, type 'make' and then >>>>>build and package the whole multiplatform distribution in a minimum of >>>>>steps. >>>>> >>>>>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>>>the Unix VM was packaged separately from the image, sources, and >>>>>changes files. I didn't see anything about 4.0 which warranted >>>>>changing this policy. >>>>> >>>>>My goal with this release was to get to a ship-able artifact as >>>>>quickly as possible while tolerating last minute changes. I very >>>>>nearly refused to update the Mac and Windows VMs in the zip files as >>>>>well, since these are really orthogonal to the mission of Squeak 4.0, >>>>>but I had some extra time so I did it anyway. >>>>> >>>>>In short, it will make more sense when these files are in their final >>>>>locations on the ftp server. >>>>> >>>>>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>>>> >>>>>> Good work. >>>>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>>>> >>>>>> Might I suggest some clear thought on naming conventions and directory organization? >>>>>> >>>>>> For example I see: >>>>>> ftp://ftp.squeak.org/4.0alpha/rc3/ >>> >>> Squeak4.0-basic.zip >>>>>> Squeak4.0-mac.zip >>>>>> Squeak4.0-win32.zip >>>>>> >>>>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>>>> >>>>>> I always try to think - write once, read many. >>>>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>>>> >>>>>> Ken G. Brown >>>>>> >>>>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>>>Ah, I should have made a statement about what's changed since RC2. >>>>>>> >>>>>>> - Newer Windows VM (3.11.8) >>>>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>>>> >>>>>>>This should make things a bit more convenient for folks intent on >>>>>>>doing the closure bootstrap. >>>>> >> >>>>>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>>>stuff in the author's local directories (instead of the correct system >>>>>>>directories) that were breaking my build process. I took John's advice >>>>>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>>>>check and make sure it still worked. >>>>>>> >>>>>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>>>> >>>>>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>>>><[hidden email]> wrote: >>>>>>>> People of Squeak, >>>>>>>> >>>>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>>>> >>>>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>>>> >>>>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>>>> problems. Classes of problems I'd consider blockers: >>>>>>>> >>>>>>>> - Broken VM >>>>>>>> - Corrupt file >>>>>>>> - Things to do with the image that potentially block relicensing >>>>>>>> >>>>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>>>> with all of the other files one usually finds there. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> -- >>>>>>>> Casey Ransberger >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>>Casey Ransberger >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Casey Ransberger >>>> >>>> >>> >>> >>> >>>-- >>>Casey Ransberger >> >> >> > > > >-- >Casey Ransberger |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Ken G. Brown
On Sat, 13 Mar 2010, Ken G. Brown wrote:
> Further: > > And I don't see any sense in rushing to meet some arbitrary deadline. Do the right thing in the right way. AFAIK there's no deadline and we are doing the right think in the right way. :) > > Keith says: > >> I know that you dont expect anyone to actually use 4.0 for real work, however we did have a list of 17 fixes that we used as a basis for building stuff on top of Squeak3.10.2 with LPF, and this image was called Squeak3.10.2-build. >> >> Out of those 17 fixes one is particularly essential, >> >> it is http://bugs.squeak.org/view.php?id=6426 >> >> I would also add 6086, 6466, 6980, 7272, 7308, and 7313 >> Thanks for the list. All but 7308 are solved/integrated in the trunk. Levente > > There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ > image that would most likely be good to get in the 4.0. > > Ken G. Brown > > > At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >> (moved the thread from vm-dev back to squeak-dev) >> >> The welcome screen. If you scroll down, all of the information about >> 3.10 is still there. >> >> As far as after release goes: Yeah. Once this thing ships, if anything >> at all needs to change, we should call it Squeak 4.0.1 or something. >> I'm hoping that won't need to happen though. It's basically the same >> as 3.10. Same basic stuff as the last release. >> >> On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >>> >>> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >>> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >>> >>> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >>> >>> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >>> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >>> >>> Ken G. Brown >>> >>> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>> Here's the plan: >>>> >>>> When I hear these bits are good, I'm going to cut a new directory for >>>> 4.0. It's contents will looks just like what's in the 3.10 directory, >>>> with the above files swapped in. The reason why you're seeing those >>>> files, and in particular why it doesn't make sense, is that you're >>>> seeing them out of context. The reason why you aren't seeing the other >>>> files and directories that generally accompany them is: the other >>>> files don't need to change for the 4.0 release. I will in effect be >>>> copying the entire 3.10 directory to 4.0, and then remove/replace the >>>> files that correspond to what's in the final release candidate. >>>> >>>> The reason I'm scripting everything is, if there's a last minute >>>> change to for example, the license text, I don't want to have to go to >>>> all the trouble to copy and zip everything manually; it's time >>>> consuming and error prone. I'm set up now to take a change to e.g., >>>> the version of the VM, or something in the image, type 'make' and then >>>> build and package the whole multiplatform distribution in a minimum of >>>> steps. >>>> >>>> The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>> the Unix VM was packaged separately from the image, sources, and >>>> changes files. I didn't see anything about 4.0 which warranted >>>> changing this policy. >>>> >>>> My goal with this release was to get to a ship-able artifact as >>>> quickly as possible while tolerating last minute changes. I very >>>> nearly refused to update the Mac and Windows VMs in the zip files as >>>> well, since these are really orthogonal to the mission of Squeak 4.0, >>>> but I had some extra time so I did it anyway. >>>> >>>> In short, it will make more sense when these files are in their final >>>> locations on the ftp server. >>>> >>>> On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>>> >>>>> Good work. >>>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>>> >>>>> Might I suggest some clear thought on naming conventions and directory organization? >>>>> >>>>> For example I see: >>>>> ftp://ftp.squeak.org/4.0alpha/rc3/ >>>>> Squeak4.0-basic.zip >>>>> Squeak4.0-mac.zip >>>>> Squeak4.0-win32.zip >>>>> >>>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>>> >>>>> I always try to think - write once, read many. >>>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>>> >>>>> Ken G. Brown >>>>> >>>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>> Ah, I should have made a statement about what's changed since RC2. >>>>>> >>>>>> - Newer Windows VM (3.11.8) >>>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>>> >>>>>> This should make things a bit more convenient for folks intent on >>>>>> doing the closure bootstrap. >>>>>> >>>>>> The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>> stuff in the author's local directories (instead of the correct system >>>>>> directories) that were breaking my build process. I took John's advice >>>>>> and simply removed the bundle. I also fired up the VM to do a sanity >>>>>> check and make sure it still worked. >>>>>> >>>>>> Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>>> >>>>>> On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>>> <[hidden email]> wrote: >>>>>>> People of Squeak, >>>>>>> >>>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>>> >>>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>>> >>>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>>> problems. Classes of problems I'd consider blockers: >>>>>>> >>>>>>> - Broken VM >>>>>>> - Corrupt file >>>>>>> - Things to do with the image that potentially block relicensing >>>>>>> >>>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>>> with all of the other files one usually finds there. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Casey Ransberger >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Casey Ransberger >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Casey Ransberger >>> >>> >> >> >> >> -- >> Casey Ransberger > > |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Casey Ransberger
On 14 March 2010 05:46, Ken G. Brown <[hidden email]> wrote:
> That was the showcase. > > It seems incredible to me that anyone would even consider rushing a major release showcase snapshot milestone that will exist forever, without > putting some due care and attention to it. > No. 4.0 is for relicensing of 3.10 (or 3.10.2 perhaps) but not about adding/fixing features comparing to these releases. Soon enough we can release next 4.x series, where all such things can be incorporated. But please, not in 4.0. We are waited quite a while for this (relicensing) to happen. > Ken G. Brown > > > > At 7:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>Keith, Ken: >> >>It pains me to say this, but 4.0 was code frozen as soon as the >>license was at the top of the sources file and the cruft was out of >>the object memory. The only purpose of the release is relicensing, and >>I'm blocking all scope beyond that. Especially two days before we're >>planning on calling it shipped. >> >>I'm really sorry guys. Normally I wouldn't turn down a bug fix, but >>this is not a regular release; it's neither feature nor quality >>driven. >> >>I'm guessing you guys aren't going to bother with integrating these >>fixes in Trunk. If that's the case, why not use them to showcase the >>Bob development process? Start with 4.0 and deploy the fixes in from >>Mantis? Could be a really good opportunity to get people exposed to, >>interested in, and ultimately rallied behind your development process. >> >>On Sat, Mar 13, 2010 at 6:51 PM, Ken G. Brown <[hidden email]> wrote: >>> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ >>> image that would most likely be good to get in the 4.0. >>> >>> Ken G. Brown >>> >>> >>> At 6:45 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>(moved the thread from vm-dev back to squeak-dev) >>>> >>>>The welcome screen. If you scroll down, all of the information about >>>>3.10 is still there. >>>> >>>>As far as after release goes: Yeah. Once this thing ships, if anything >>>>at all needs to change, we should call it Squeak 4.0.1 or something. >>>>I'm hoping that won't need to happen though. It's basically the same >>>>as 3.10. Same basic stuff as the last release. >>>> >>>>On Sat, Mar 13, 2010 at 6:38 PM, Ken G. Brown <[hidden email]> wrote: >>>>> >>>>> Well my point is if you are eventually going to need basic. full, and core or whatever, you should start off with the naming convention to allow for that. >>>>> And you might want to consider having some way to know what the starting point was for each image, whether it be in the readme file or by naming conventions. >>>>> >>>>> There should be some way of knowing that the images were 3.10.2-7159 based, now called 4.0. You always want to keep track of how each was derived in case you need to do it over again. Saving the eact script versions that created each would be a good idea too. And never ever change anything in a script without changing the script version number. >>>>> >>>>> And once you release, you never want to change a zipped file without changing the version. People may depend on it. >>>>> A person doesn't want to redownload something later on only to find someone has sneakily changed it and now it is different. >>>>> >>>>> Ken G. Brown >>>>> >>>>> At 6:03 PM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>>Here's the plan: >>>>>> >>>>>>When I hear these bits are good, I'm going to cut a new directory for >>>>>>4.0. It's contents will looks just like what's in the 3.10 directory, >>>>>>with the above files swapped in. The reason why you're seeing those >>>>>>files, and in particular why it doesn't make sense, is that you're >>>>>>seeing them out of context. The reason why you aren't seeing the other >>>>>>files and directories that generally accompany them is: the other >>>>>>files don't need to change for the 4.0 release. I will in effect be >>>>>>copying the entire 3.10 directory to 4.0, and then remove/replace the >>>>>>files that correspond to what's in the final release candidate. >>>>>> >>>>>>The reason I'm scripting everything is, if there's a last minute >>>>>>change to for example, the license text, I don't want to have to go to >>>>>>all the trouble to copy and zip everything manually; it's time >>>>>>consuming and error prone. I'm set up now to take a change to e.g., >> >>>>the version of the VM, or something in the image, type 'make' and then >>>>>>build and package the whole multiplatform distribution in a minimum of >>>>>>steps. >>>>>> >>>>>>The reason Squeak4.0-basic.zip doesn't make sense is: traditionally >>>>>>the Unix VM was packaged separately from the image, sources, and >>>>>>changes files. I didn't see anything about 4.0 which warranted >>>>>>changing this policy. >>>>>> >>>>>>My goal with this release was to get to a ship-able artifact as >>>>>>quickly as possible while tolerating last minute changes. I very >>>>>>nearly refused to update the Mac and Windows VMs in the zip files as >>>>>>well, since these are really orthogonal to the mission of Squeak 4.0, >>>>>>but I had some extra time so I did it anyway. >>>>>> >>>>>>In short, it will make more sense when these files are in their final >>>>>>locations on the ftp server. >>>>>> >>>>>>On Sat, Mar 13, 2010 at 4:41 PM, Ken G. Brown <[hidden email]> wrote: >>>>>>> >>>>>>> Good work. >>>>>>> I was wondering why you needed to go to all the trouble with scripting and whatnot for Mac? >>>>>>> Don't you just drag the files into a folder and cntl-Compress from the context menu? >>>>>>> >>>>>>> Might I suggest some clear thought on naming conventions and directory organization? >>>>>>> >>>>>>> For example I see: >>>>>>> ftp://ftp.squeak.org/4.0alpha/rc3/ >>>> >>> Squeak4.0-basic.zip >>>>>>> Squeak4.0-mac.zip >>>>>>> Squeak4.0-win32.zip >>>>>>> >>>>>>> So how does Squeak4.0-basic.zip differ from the others? Is Squeak4.0-mac.zip = basic or something else? >>>>>>> When I unzip a file, I expect to get a folder with the same name. Other people don't I know, but it might be something to consider. >>>>>>> >>>>>>> I always try to think - write once, read many. >>>>>>> Try to have a naming convention that will keep the confusion demons away for the long term future. >>>>>>> >>>>>>> Ken G. Brown >>>>>>> >>>>>>> At 11:28 AM -0800 3/13/10, Casey Ransberger apparently wrote: >>>>>>>>Ah, I should have made a statement about what's changed since RC2. >>>>>>>> >>>>>>>> - Newer Windows VM (3.11.8) >>>>>>>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had issues) >>>>>>>> >>>>>>>>This should make things a bit more convenient for folks intent on >>>>>>>>doing the closure bootstrap. >>>>>> >> >>>>>>>>The reason I removed SparklePlugin.bundle: it had some symlinks to >>>>>>>>stuff in the author's local directories (instead of the correct system >>>>>>>>directories) that were breaking my build process. I took John's advice >>>>>>>>and simply removed the bundle. I also fired up the VM to do a sanity >>>>>>>>check and make sure it still worked. >>>>>>>> >>>>>>>>Thanks everyone! Freedom tastes better than cheese! Say no to mouse traps! >>>>>>>> >>>>>>>>On Sat, Mar 13, 2010 at 11:18 AM, Casey Ransberger >>>>>>>><[hidden email]> wrote: >>>>>>>>> People of Squeak, >>>>>>>>> >>>>>>>>> The RC3 distribution of Squeak 4.0 is now available at: >>>>>>>>> >>>>>>>>> http://ftp.squeak.org/4.0alpha/Squeak4.0.rc3.tar.gz >>>>>>>>> http://ftp.squeak.org/4.0alpha/rc3/ >>>>>>>>> >>>>>>>>> Please chip in, test it out, and reply to this thread if you see any >>>>>>>>> problems. Classes of problems I'd consider blockers: >>>>>>>>> >>>>>>>>> - Broken VM >>>>>>>>> - Corrupt file >>>>>>>>> - Things to do with the image that potentially block relicensing >>>>>>>>> >>>>>>>>> If all is well, I will go ahead and roll the 4.0 directory structure >>>>>>>>> with all of the other files one usually finds there. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Casey Ransberger >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>Casey Ransberger >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Casey Ransberger >>>>> >>>>> >>>> >>>> >>>> >>>>-- >>>>Casey Ransberger >>> >>> >>> >> >> >> >>-- >>Casey Ransberger > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Casey Ransberger
On 3/13/10 8:42 PM, "Casey Ransberger" <[hidden email]> wrote: > Not sure about the test failures. I am hesitant to take time to fix > them and ship another RC; remember, 4.0 needs to work only well enough > to salvage. What matters is the relicense and entrance into the SFC. I > am not somewhere where I can access Squeak right now. Which tests are > failing? > > On Sat, Mar 13, 2010 at 1:29 PM, Michael Davies > <[hidden email]> wrote: >> On 13 March 2010 20:28, Casey Ransberger <[hidden email]> wrote: >>> >>> Ah, I should have made a statement about what's changed since RC2. >>> >>> - Newer Windows VM (3.11.8) >>> - Newer Mac VM (4.2.2beta1U, with SparklePlugin.bundle removed, it had >>> issues) >>> >> >> Loads fine here on OS X (10.5.8). >> TestRunner runs 2254 test, gets 1 failure, 2 errors. Is this expected? >> >> It's a bit of shock to see what bare Squeak looks like, but I guess that's >> not a blocker :-). >> >> Test never gives us all green in 3.10. If the code is the same , couldn't be better. Edgar |
|
|
In reply to this post by Casey Ransberger
On 13 March 2010 23:42, Casey Ransberger <[hidden email]> wrote:
Not sure about the test failures. I am hesitant to take time to fix Fair enough. I am not somewhere where I can access Squeak right now. Which tests are failing? For reference the problems were Failure: DebuggerUnwindBug>>#testUnwindDebuggerWithStep Errors: LocaleTest>>#testLocaleChanged SMDependencyTest>>#test2 |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Ken G. Brown
>>>>> "Ken" == Ken G Brown <[hidden email]> writes:
Ken> It seems incredible to me that anyone would even consider rushing a major Ken> release showcase snapshot milestone that will exist forever, without Ken> putting some due care and attention to it. We're putting plenty of care into it, but the care is not *technical*. It's *legal* care. We needed a fixed point for evaluation of the legal status of contributions to Squeak. 3.10.2 was chosen as the fixed point, being the most up-to-date release at the time. We then decided that a condense-sources operation was essential to ensuring that only currently-licensed code was available in the distribution, and the right way to do this is a version number bump. (Not repeating the 3.9 fiasco there.) It's also convenient to say "squeak prior to 4.0 has license X, squeak after 4.0 has license y". So the 4.0 is a legal release, and 4.1 (very soon) will be a feature and bugfix release. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Ken G. Brown
>>>>> "Ken" == Ken G Brown <[hidden email]> writes:
Ken> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ Ken> image that would most likely be good to get in the 4.0. In 4.1, yes. 4.0, no. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
Well, I disagree with the decision.
You had at least two available starting points, 3.10.2 and 3.10.2-build, -buiild was clearly better and available since June 28, 2009 (before trunk). The fixes and additions to 3.10.2 in -build were clearly documented in the info file on the ftp site, Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. And you all are choosing the one that was inferior as a starting point. It's like running a race and intentionally trying for second place. But so be it. The community will have to live with the choice. Ken G. Brown At 12:02 PM -0700 3/14/10, Randal L. Schwartz apparently wrote: > >>>>> "Ken" == Ken G Brown <[hidden email]> writes: > >Ken> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ >Ken> image that would most likely be good to get in the 4.0. > >In 4.1, yes. 4.0, no. > >-- >Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 ><[hidden email]> <URL:http://www.stonehenge.com/merlyn/> >Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Randal L. Schwartz
2010/3/14 Ken G. Brown <[hidden email]>:
> Well, I disagree with the decision. > > You had at least two available starting points, 3.10.2 and 3.10.2-build, -buiild was clearly better and available since June 28, 2009 (before trunk). > The fixes and additions to 3.10.2 in -build were clearly documented in the info file on the ftp site, Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. > And you all are choosing the one that was inferior as a starting point. > > It's like running a race and intentionally trying for second place. > > But so be it. The community will have to live with the choice. > > Ken G. Brown > Yes, that's an unfortunate waste of time. If only it were named 3.10.3, then no doubt it would have been a starting point for both trunk and 4.0. But 3.10.2-build, what is it ? You know very well that it results from task assigned to Keith, not really oriented in producing an updated image but an update process. So this 3.10.2-build is just a by-product of Keith's process, a proof of concept. Or is it more than that ? the name does not tell... The fact that the author retracted any support did not help. Sure, that could have evolved differently with better communication. Now, it's too late. Trunk is based on 3.10.2, and basing 4.0 another starting point will just add un-nexessary complications. So what do you suggest, erase trunk efforts? Nicolas > At 12:02 PM -0700 3/14/10, Randal L. Schwartz apparently wrote: >> >>>>> "Ken" == Ken G Brown <[hidden email]> writes: >> >>Ken> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ >>Ken> image that would most likely be good to get in the 4.0. >> >>In 4.1, yes. 4.0, no. >> >>-- >>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >><[hidden email]> <URL:http://www.stonehenge.com/merlyn/> >>Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >>See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > > > |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Ken G. Brown
>>>>> "Ken" == Ken G Brown <[hidden email]> writes:
Ken> You had at least two available starting points, 3.10.2 and 3.10.2-build, Ken> -buiild was clearly better and available since June 28, 2009 (before Ken> trunk). The fixes and additions to 3.10.2 in -build were clearly Ken> documented in the info file on the ftp site, Ken> Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. And Ken> you all are choosing the one that was inferior as a starting point. I think I could find at least a dozen squeak developers here who would agree with me that if 3.10.2-build was a fixed point, it's a bad name for a release, and if it was a moving point, it would be a bad place to start the legal process. Had that been released as 3.10.3, or 3.11, your point would have merit. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
Re: [Vm-dev] Re: [Squeak 4.0] RC3 is out
|
|
In reply to this post by Nicolas Cellier
At 10:17 PM +0100 3/14/10, Nicolas Cellier apparently wrote:
>2010/3/14 Ken G. Brown <[hidden email]>: >> Well, I disagree with the decision. >> >> You had at least two available starting points, 3.10.2 and 3.10.2-build, -buiild was clearly better and available since June 28, 2009 (before trunk). >> The fixes and additions to 3.10.2 in -build were clearly documented in the info file on the ftp site, Squeak3.10.2-build/090628-1523/090628-1523_Squeak3.10.2-build.info. >> And you all are choosing the one that was inferior as a starting point. >> >> It's like running a race and intentionally trying for second place. >> >> But so be it. The community will have to live with the choice. >> >> Ken G. Brown >> > >Yes, that's an unfortunate waste of time. >If only it were named 3.10.3, then no doubt it would have been a >starting point for both trunk and 4.0. >But 3.10.2-build, what is it ? >You know very well that it results from task assigned to Keith, not >really oriented in producing an updated image but an update process. That I believe is a bit of misinformation. It was always about producing the tools that automated the repeatable building of updated images, any one of which could be designated a 'release'. You know very well what the -build was/is. It has been explained over and over again. >So this 3.10.2-build is just a by-product of Keith's process, a proof >of concept. Or is it more than that ? the name does not tell... It was the starter with the minimum stuff added over 3.10.2 necessary for building images, whichever you want. >The fact that the author retracted any support did not help. >Sure, that could have evolved differently with better communication. >Now, it's too late. It's not too late...yet. Will be soon. >Trunk is based on 3.10.2, and basing 4.0 another >starting point will just add un-nexessary complications. >So what do you suggest, erase trunk efforts? Make trunk updates load on 3.10.2-build, then base 4.0 on 3.10.2-build call it 3.10.3 if you like. Ken G. Brown >Nicolas > >> At 12:02 PM -0700 3/14/10, Randal L. Schwartz apparently wrote: >>> >>>>> "Ken" == Ken G Brown <[hidden email]> writes: >>> >>>Ken> There were some important fixes in Keith's ftp://ftp.squeak.org/3.11-obsolete/Squeak3.10.2-build/ >>>Ken> image that would most likely be good to get in the 4.0. >>> >>>In 4.1, yes. 4.0, no. >>> >>>-- >>>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >>><[hidden email]> <URL:http://www.stonehenge.com/merlyn/> >>>Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >>>See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion >> >> >> |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |