http://ftp.squeak.org/4.4/Squeak4.4-12303.zip
I suggest we use a consistent naming convention that conveys the general ("4.4") and specific ("-12303") version information. After a week has gone by for the community to download and verify it, there is no need to deploy yet another (renamed) image, so the "candidate" is truly a candidate for release -- the one that was tested. Then all we have to do is [ANN]ounce. That it is in the "4.4" release directory rather than the "4.4alpha" directory, anyone will know this is THE candidate for release. In the past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" -- which could still do for alpha images if we want to be sure the names themselves carry a "quality disclaimer" tag. |
On Sun, Dec 16, 2012 at 03:16:23PM -0600, Chris Muller wrote:
> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip > > I suggest we use a consistent naming convention that conveys the > general ("4.4") and specific ("-12303") version information. After a > week has gone by for the community to download and verify it, there is > no need to deploy yet another (renamed) image, so the "candidate" is > truly a candidate for release -- the one that was tested. Then all we > have to do is [ANN]ounce. Yay! One glitch - the image and changes files unpack as read-only on my (linux) box. If you could re-zip them after a chmod +w, that might save some confusion. And a SqueakMap issue (?) The Squeak version is "Squeak4.4" and the version tag in SqueakMap is "Squeak 4.4". I think this may be causing SqueakMap to say that the "Squeak 4.4" packages are not compatible with the image. Thanks, Dave |
In reply to this post by Chris Muller-3
On 2012-12-16 4:16 PM, Chris Muller wrote:
> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip > > I suggest we use a consistent naming convention that conveys the > general ("4.4") and specific ("-12303") version information. After a > week has gone by for the community to download and verify it, there is > no need to deploy yet another (renamed) image, so the "candidate" is > truly a candidate for release -- the one that was tested. Then all we > have to do is [ANN]ounce. > > That it is in the "4.4" release directory rather than the "4.4alpha" > directory, anyone will know this is THE candidate for release. In the > past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" > -- which could still do for alpha images if we want to be sure the > names themselves carry a "quality disclaimer" tag. > up beyond the World. Fits perfectly always. Chris |
In reply to this post by Chris Muller-3
On 2012-12-16 4:16 PM, Chris Muller
wrote:
http://ftp.squeak.org/4.4/Squeak4.4-12303.zip I suggest we use a consistent naming convention that conveys the general ("4.4") and specific ("-12303") version information. After a week has gone by for the community to download and verify it, there is no need to deploy yet another (renamed) image, so the "candidate" is truly a candidate for release -- the one that was tested. Then all we have to do is [ANN]ounce. That it is in the "4.4" release directory rather than the "4.4alpha" directory, anyone will know this is THE candidate for release. In the past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" -- which could still do for alpha images if we want to be sure the names themselves carry a "quality disclaimer" tag. Smalltalk appendChangesTo: 'SqueakV44.sources'Would shrink the image a couple of M, but fails with Error: Unmatched string quote. (It failed when I tried to use it on 4.3 as well. Which is why Squeak 4.3 did not have a SqueakV43.sources) Smalltalk unloadAllKnownPackages in the Future Directions welcome workspace fails with Error: Unmatched string quote. Both of those problems relate to the Scanner. Chris |
In reply to this post by Chris Muller-3
Feedback:
When you open a browser in the new image, the "instance" button is not large enough. Also, why have system windows become so narrow ? It makes them really impractical IMO. Stef |
> Also, why have system windows become so narrow ? It makes them really
> impractical IMO. RealEstateAgent initialize makes them 600@400 again, so I guess this is a glitch in the image building. Stef |
In reply to this post by Chris Muller-3
On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote:
> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip > > I suggest we use a consistent naming convention that conveys the > general ("4.4") and specific ("-12303") version information. After a > week has gone by for the community to download and verify it, there is > no need to deploy yet another (renamed) image, so the "candidate" is > truly a candidate for release -- the one that was tested. Then all we > have to do is [ANN]ounce. > > That it is in the "4.4" release directory rather than the "4.4alpha" > directory, anyone will know this is THE candidate for release. Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version. > In the > past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" > -- which could still do for alpha images if we want to be sure the > names themselves carry a "quality disclaimer" tag. I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all: http://en.wikipedia.org/wiki/Software_release_life_cycle - Bert - |
In reply to this post by Stéphane Rollandin
On 17 December 2012 10:09, Stéphane Rollandin <[hidden email]> wrote:
>> Also, why have system windows become so narrow ? It makes them really >> impractical IMO. > > > RealEstateAgent initialize makes them 600@400 again, so I guess this is a > glitch in the image building. I noticed this and thought I'd fixed it. At any rate, it's definitely fixed now, and a new version's ready for deployment as soon as some admin's done. frank > Stef > |
In reply to this post by Bert Freudenberg
On 17 December 2012 12:12, Bert Freudenberg <[hidden email]> wrote:
> On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote: > >> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip >> >> I suggest we use a consistent naming convention that conveys the >> general ("4.4") and specific ("-12303") version information. After a >> week has gone by for the community to download and verify it, there is >> no need to deploy yet another (renamed) image, so the "candidate" is >> truly a candidate for release -- the one that was tested. Then all we >> have to do is [ANN]ounce. I would in general be happy with this convention, but right now it's a lie: this image is 12303 + my ReleaseBuilder and Morphic hacks, which are in the Inbox (deliberately so) and NOT in trunk. If people are OK with what they see (other than the 500@400 glitch Stef caught), I can move these into trunk, and we can have a 12303+n version. frank >> That it is in the "4.4" release directory rather than the "4.4alpha" >> directory, anyone will know this is THE candidate for release. > > Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version. > >> In the >> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" >> -- which could still do for alpha images if we want to be sure the >> names themselves carry a "quality disclaimer" tag. > > I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all: > > http://en.wikipedia.org/wiki/Software_release_life_cycle > > - Bert - > > > |
On 17 December 2012 12:22, Frank Shearar <[hidden email]> wrote:
> On 17 December 2012 12:12, Bert Freudenberg <[hidden email]> wrote: >> On 2012-12-16, at 22:16, Chris Muller <[hidden email]> wrote: >> >>> http://ftp.squeak.org/4.4/Squeak4.4-12303.zip >>> >>> I suggest we use a consistent naming convention that conveys the >>> general ("4.4") and specific ("-12303") version information. After a >>> week has gone by for the community to download and verify it, there is >>> no need to deploy yet another (renamed) image, so the "candidate" is >>> truly a candidate for release -- the one that was tested. Then all we >>> have to do is [ANN]ounce. > > I would in general be happy with this convention, but right now it's a > lie: this image is 12303 + my ReleaseBuilder and Morphic hacks, which > are in the Inbox (deliberately so) and NOT in trunk. I've just released (with help from Bert), the next iteration; http://ftp.squeak.org/4.4/Squeak4.4-RC2.tgz This fixes the 500@400 problem, the doubled Welcome Workspaces (not immediately apparent because the new windows lay on top of the old windows) and forces #useOldNetwork:. frank > If people are OK with what they see (other than the 500@400 glitch > Stef caught), I can move these into trunk, and we can have a 12303+n > version. > > frank > >>> That it is in the "4.4" release directory rather than the "4.4alpha" >>> directory, anyone will know this is THE candidate for release. >> >> Nobody can know this from the URL. It looks like an actual release, because *nothing* indicates that this is not a stable version. >> >>> In the >>> past we have tagged alpha images as, e.g., "Squeak4.2alpha-10160.zip" >>> -- which could still do for alpha images if we want to be sure the >>> names themselves carry a "quality disclaimer" tag. >> >> I'd prefer this, yes. Although we're way past alpha. This is a release candidate, after all: >> >> http://en.wikipedia.org/wiki/Software_release_life_cycle >> >> - Bert - >> >> >> |
I get a bunch of Monticello test failures and errors.
Failures: 3272 run, 3227 passes, 18 expected failures, 17 failures, 10 errors, 0 unexpected passes LocaleTest>>#testLocaleChanged MCChangeNotificationTest>>#testCoreMethodModified MCFileInTest>>#testStWriter MCPackageTest>>#testUnload MCPatchTest>>#testPatchContents MCSnapshotBrowserTest>>#testNoSelection MCSnapshotTest>>#testCreation MCStWriterTest>>#testMethodDefinition MCStWriterTest>>#testOrganizationDefinition MCWorkingCopyTest>>#testBackport MCWorkingCopyTest>>#testOptimizedLoad MCWorkingCopyTest>>#testRepeatedMerge MCWorkingCopyTest>>#testSelectiveBackport MCWorkingCopyTest>>#testSimpleMerge MCWorkingCopyTest>>#testSnapshotAndLoad SocketTest>>#testSocketReuse SocketTest>>#testUDP Errors: MCChangeNotificationTest>>#testExtMethodModified MCSnapshotBrowserTest>>#testCategorySelected MCSnapshotBrowserTest>>#testClassSelected MCSnapshotBrowserTest>>#testClassSideClassSelected MCSnapshotBrowserTest>>#testComment MCSnapshotBrowserTest>>#testMethodIsCleared MCSnapshotBrowserTest>>#testMethodSelected MCSnapshotBrowserTest>>#testProtocolIsCleared MCSnapshotBrowserTest>>#testProtocolSelected MCStWriterTest>>#testInitializerDefinition |
On 17 December 2012 15:20, glenpaling <[hidden email]> wrote:
> I get a bunch of Monticello test failures and errors. Thanks for trying it out, Glen. I assume this is on OS X, right? > Failures: > 3272 run, 3227 passes, 18 expected failures, 17 failures, 10 errors, 0 > unexpected passes > LocaleTest>>#testLocaleChanged This one's known to be a broken test. > MCChangeNotificationTest>>#testCoreMethodModified > MCFileInTest>>#testStWriter > MCPackageTest>>#testUnload > MCPatchTest>>#testPatchContents > MCSnapshotBrowserTest>>#testNoSelection > MCSnapshotTest>>#testCreation > MCStWriterTest>>#testMethodDefinition > MCStWriterTest>>#testOrganizationDefinition > MCWorkingCopyTest>>#testBackport > MCWorkingCopyTest>>#testOptimizedLoad > MCWorkingCopyTest>>#testRepeatedMerge > MCWorkingCopyTest>>#testSelectiveBackport > MCWorkingCopyTest>>#testSimpleMerge > MCWorkingCopyTest>>#testSnapshotAndLoad Hm, these are unexpected, and shouldn't be platform specific, and also don't occur on the CI server. > SocketTest>>#testSocketReuse > SocketTest>>#testUDP These might / are probably platform specific test failures: they don't occur in CI, but CI runs on a Linux machine. > Errors: > MCChangeNotificationTest>>#testExtMethodModified > MCSnapshotBrowserTest>>#testCategorySelected > MCSnapshotBrowserTest>>#testClassSelected > MCSnapshotBrowserTest>>#testClassSideClassSelected > MCSnapshotBrowserTest>>#testComment > MCSnapshotBrowserTest>>#testMethodIsCleared > MCSnapshotBrowserTest>>#testMethodSelected > MCSnapshotBrowserTest>>#testProtocolIsCleared > MCSnapshotBrowserTest>>#testProtocolSelected > MCStWriterTest>>#testInitializerDefinition These too are unexpected. Any chance of getting exception messages or stack traces or similar for them? (You _should_ be able to wangle the info out of the TestRunner by iterating over its TestCases, but I forget the precise incantation to use.) frank |
Yes, the Locale and socket test failures are fairly long standing. All the MC failures are quite new. I've been on an internet starved vacation in Mexico, so I'm a little behind in tests. I ran CI build 60, it didn't have the MC problems. I'll to get more details.
|
In reply to this post by Frank Shearar-3
My XP laptop has the same failures and OSX plus:
Failure: Win32VMTest>>#testWinVM3ButtonMousePreference and Error: FileDirectoryTest>>#testExtMethodModified |
On 17 December 2012 15:58, glenpaling <[hidden email]> wrote:
> My XP laptop has the same failures and OSX plus: > Failure: Win32VMTest>>#testWinVM3ButtonMousePreference > and Error: FileDirectoryTest>>#testExtMethodModified I'm also seeing the MC failures. MCChangeNotificationTest >> #testCoreMethodModified fails, for instance, because MCMockClassA has no #one method, and the test expects there to be one. And yet the build on CI doesn't see these test failures! frank |
I updated the CI build version 60 I had to trunk version 12303 (same version as RC2). The tests run without Monticello failures. Looks like a CI problem.
|
On 17 December 2012 17:07, glenpaling <[hidden email]> wrote:
> I updated the CI build version 60 I had to trunk version 12303 (same version > as RC2). The tests run without Monticello failures. Looks like a CI > problem. No, because build 60 had only 3 test failures. Too, builds #61 - #63 weren't triggered by MC changes, so they're running the same MC tests, and none of them failed with these errors. I don't know _why_ it's happening, but I think I know _where_: MCMethodDefinitionTest >> testLoadAndUnload |definition| definition := self mockMethod: #one class: 'MCMockClassA' source: 'one ^2' meta: false. self assert: self mockInstanceA one = 1. definition load. self assert: self mockInstanceA one = 2. definition unload. self deny: (self mockInstanceA respondsTo: #one) However, its #tearDown is supposed to restore order, and is apparently not. frank |
On 17 December 2012 17:12, Frank Shearar <[hidden email]> wrote:
> On 17 December 2012 17:07, glenpaling <[hidden email]> wrote: >> I updated the CI build version 60 I had to trunk version 12303 (same version >> as RC2). The tests run without Monticello failures. Looks like a CI >> problem. > > No, because build 60 had only 3 test failures. Too, builds #61 - #63 > weren't triggered by MC changes, so they're running the same MC tests, > and none of them failed with these errors. > > I don't know _why_ it's happening, but I think I know _where_: > > MCMethodDefinitionTest >> testLoadAndUnload > |definition| > definition := self mockMethod: #one class: 'MCMockClassA' source: > 'one ^2' meta: false. > self assert: self mockInstanceA one = 1. > definition load. > self assert: self mockInstanceA one = 2. > definition unload. > self deny: (self mockInstanceA respondsTo: #one) > > However, its #tearDown is supposed to restore order, and is apparently not. Glen, when you run the tests, do you have Author initials set? I've just found that if I _don't_, then the #tearDown doesn't revert the mock MC package properly... but if I _do_, then the tests pass. (The CI build explicitly sets the Author initials.) |
Yes, I'm setting the AuthorInitials. I checked, it's still set to 'egp'. I located a version of Squeak4.4-alpha (update: 11920). It passes the MC tests. |
Frank, I downloaded the SqueakTrunk #64 build artifacts directly from http://www.squeakci.org/job/SqueakTrunk/lastBuild/?. Test have no Monticello failures just:
3272 run, 3250 passes, 18 expected failures, 4 failures, 0 errors, 0 unexpected passes LocaleTest>>#testLocaleChanged SocketTest>>#testSocketReuse SocketTest>>#testUDP WeakSetInspectorTest>>#testSymbolTableM6812 |
Free forum by Nabble | Edit this page |