[squeak-dev] Release details - core dump ( was Squeak release process)

Chris Cunnington smalltalktelevision at gmail.com
Mon Jul 16 14:48:13 UTC 2012


As I knew nothing about the release process while releasing 4.3, I made 
a lot of lists on the Squeak Board for other, wiser people to vet. Here 
are 10 posts shooting details of that process in all directions. If 
you'd like to collate this material, you have my respect. I'm not mad 
keen to relive the experience by reading this stuff over and over. All 
the names are removed, so I hope I'm not exposing the privacy of any of 
my fellow Board members.

Chris


Post #1:

/source43 needs to be created

ReleaseBuilderTrunk class #transferCurrentPackages needs to be executed to populate that repository

#prepareNewBuild needs to be executed on an alpha image to produce the final image

#prepareNewBuild has several related selectors that I need to update changing 2s to 3s and such. It also points to TheWorldMainDockingBar, where my work really is. I need to make it produce two Workspaces as a result of #prepareNewBuild.

The two workspaces contain: what's new in this image; what's the future plan for Squeak.

XXX hasn't seen the swatch that I chose, which has been vetted, and approved, and we're going with:

http://www.16r.ca/ricepaper.jpg

I've been using Form openAsBackground: to put the image in the world. This produces an InfiniteForm. If you take any alpha image and execute InfiniteForm allInstances you will find one, the one Andreas used for 4.1. It's still in there. RBT class #setBackground may need to be jettisoned or World color: InfiniteForm added or something.

Contents of Workspace #2:

Package Management

- This image is currently 16M. If you execute - Smalltalk unloadAllKnownPackages - it will quickly become ~10M

- The SqueakCore image is available athttp://ftp.squeak.org/4.3

- A reasonable target for a core image is 5M, so a drop of ~5M from the smallest image is a task before the community

- A place to explore where to make reductions is likely the removal/replacement of GUIs

- Once we have a smaller core image, we can enact the Andreas Raab memo [1] on how to load code back into the smaller image. This will be based on tests which will clearly delineate the responsibilities of core developers and application developers.

  [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html

and Workspace #1:

Workspace are Squeak 4.3 - Rice Paper

Changes in this release:

	- better control of socket connection timeouts
	- blocks and MessageSends are exchangeable in more situations
	- added support for threaded VMs
	- rejection of literals with superfluous # at the beginning, like #$a #123 ##foo ##(1 2 3), etc
	- specify packages either with or without a version-number in Installer
	- corrected Complex so arcSin and arcCos let (1 arTanh) return inf
	- extend support for MCConfigurations to regular MCDirectoryRepositorys
	- full-screen toggle option has been moved out from the menu and onto the bar directly just to the right of the clock for one-click access
	- TextEditor is event driven; sensor usage is banned from it
	-  ancient behavior of selecting whole text when clicking twice before first, or twice after last character is restored
	- drag/drop between inspectors; drag a field onto another field to replace the object in it.
	- Compiler changed to create subclasses of CompiledMethod
	- updated button for "what to show" on CodeHolder similar to Squeak 3.8
	- changes enabling both Yellow and Blue buttons from a two-button mouse in Cog VM
	- SMxMorphicProject now able to host a SimpleMorphic World
	- when present, a SMxMorphicProject is made available in the world menu


Those are the broad strokes. I figure that after this email my only real job will be to submit changes to ReleaseBuilderTrunk and TheWorldMainDockingBar to the Inbox. I will do that early next week. After that, I figure my duty is discharged.

It is to be hoped that we will release the Squeak 4.3 image immediately after the 20th SOB meeting.
If there is anything I have missed in the changes to this release list, please add it.


Post #2:

It's almost perfect, but I'd like to see three changes. The most important
is to save the image from a non-Cog VM, otherwise it cannot be opened on
Windows (and IIRC on Mac) with the interpreter VM.
The other two things are about packaging, so they may be irrelevant (in
case this zip file is not the one which will be available for download):
- the sources file should not be in the zip
- the mac specific files and directories (_MACOSX, ._.DSTORE,
etc) also shouldn't be in the zip

Post #3:


Well, you can delete them on the command line:

	zip -d /Users/bert/Downloads/Squeak4.3.zip __MACOSX/\*

For the release itself, I noticed these issues:

- window is too small (784x548). Not even the world menu fits. I'd make it 1024x768 at least.
- shouldn't all Welcome Workspaces be open (or at least minimized)?
- default change set not empty
- Exceptions package is marked dirty
- changes file not empty
   (Smalltalk appendChangesTo: 'SqueakV43.sources')
   (we didn't do this for 4.2, but it would save 2 MB)
- no update map that matches released packages yet

Non of these are really showstoppers, but maybe having a decent window size and the workspaces open would be nicer to newcomers? At the very least, the license thing?


Post #4:


<process>

trim names of folder, image and changes

ChangeSet allChangeSets: OrderedCollection new

Form openAsBackground:

Smalltalk appendChangesTo: 'SqueakV43.sources'

ReleaseBuilderTrunk prepareNewBuild

open shell to delete .DS_Store from folder

compress

check with Stuffit Archive Manager that there are no artifacts

</process>


<left undone>
pushing changes to ReleaseBuilderTrunk into inbox

update map

?
</left undone>


Post #5:

<process>

take Squeak4.3gamma-11793.zip

update from trunk

now 11852

trim names of folder, image and changes

pull open to ~1024x768 and save (explore World to check)

Form openAsBackground: '/Users/chriscunnington/Desktop/ricepaper.jpg'

Smalltalk appendChangesTo: 'SqueakV43.sources'

ReleaseBuilderTrunk prepareNewBuild

ChangeSet cleanUp: true

compress with Zip Files 4 PC

</process>


<left undone>

update map

SmalltalkImage unloadAllKnownPackages is broken

</left undone>


Post #6:


I was sort of dancing around it, but yea, the RBTrunk doesn't seem to have a direct control of the screen size in my Mac. I've been doing it by hand and checking it by exploring World.

I'lll ensure it's ~800 at 600  <http://lists.squeakfoundation.org/mailman/listinfo/board>  or a tad bigger depending on the steadiness of my hand. I'll return the size in #prepareNewBuild to what it was initially. At this point I'd prefer to forego the Etoys code you added this time around and do it by hand. I suppose this means I should upload a change to the Trunk to return things to what they we're. I'm not keen to keep putting things into the trunk just to change them, so I'll hold off on that.

As far as I can see, there are only two things left to do:

<left undone>

update map

as per XXX's email, figure out why the sources file is built corrupted
(Yea, the AbstractSound>>+ message will throw the warning about corrupted sources.)

</left undone>

In a pinch I could abandon both and package an image and changes file to work with 41sources.

Owing to an email from XXX., it seems I needn't think I've run out of time.
That being the case I'll pursue these things today.


Post #7:


I agree with your reasoning. There is one problem: shrinkage. It starts at800 at 600.  <http://lists.squeakfoundation.org/mailman/listinfo/board>  
And it says that, and has for a long time,800 at 600  <http://lists.squeakfoundation.org/mailman/listinfo/board>  in #prepareNewBuild.
Then I execute #prepareNewBuild and it shrinks to something like786 at 548.  <http://lists.squeakfoundation.org/mailman/listinfo/board>  
I kid thee not.
I figure I'll just drag it back to shape and test it with World extent before saving afterward.

FWIW, #prepareNewBuild is always a weird experience on my Mac. My screen resolution
changes to something much lower. So everything becomes huge. I save and quit the
image and the resolution returns to normal. Odd.


Post #8:


<process>

using Squeak4.3gamma-11860

trim names of folder, image and changes

Form openAsBackground: '/Users/chriscunnington/Desktop/ricepaper.jpg'

ReleaseBuilderTrunk prepareNewBuild

ChangeSet cleanUp: true

check the size  with World extent;  ensure it's800 at 600  <http://lists.squeakfoundation.org/mailman/listinfo/board>

compress with Zip Files 4 PC

</process>

<left undone>

Smalltalk appendChangesTo: 'SqueakV43.sources'

</left undone>

I think this may be the one. I moved the update-the-map task to a post-image-build list of release related tasks. That list is below. The reason is once you do that the image you used is polluted and is not the one to be distributed. That task can happen the second we have a final image to distribute, it seems to me.

I moved #appendChangesTo: to the left undone category, where I think it should stay until 4.4. Something is creating a compromised source file. I'm not the one to know why. If anybody wants to add to the Trunk to fix this problem, I'll jump at making another image, because I think the result is cool: new sources file; changes file under 1K (which makes me laugh).

As such this packaging has no sources file, as it's assumed we'd use SqueakV41.sources.

If this is the one, then please put it in the box, and post a url, so I can announce on Squeak-dev.

Thanks,


< release related tasks>
- update the map
- a ftp.squeak.org/4.3 folder
- a SqueakCore image at ftp.squeak.org/4.3
- link from squeak.org homepage
- announcement on Squeak News, G+ etc.
</release related tasks>


Post #9:


I've updated the map. I took a Squeak4.3gamma-11793 and updated from /squeak43. It took longer than I'd suppose, but it did update from the map.
It would be good if somebody could try that as well. And perhaps look athttp://source.squeak.org/squeak43  to see if things look right.

On the surface of it, I should be using ReleaseBuilderTrunk>>#transferCurrentPackages, but that did not pan out, so I did it manually in a Workspace. My rant on that is below.

If the things I've done recently are in order, then we only need to do two things: upload two zipped files to the 4.3 ftp folder, and change the link on the homepage of squeak.org to the All-In-One application.

Thanks,


<rant>

transferCurrentPackages
	| trunkRep releaseRep |
	trunkRep := self trunkRepository.
	releaseRep := self releaseRepository.
	MCWorkingCopy allManagers
		do: [:eachWorkingCopy | eachWorkingCopy ancestors
				do: [:eachVersionInfo | (releaseRep includesVersionNamed: eachVersionInfo versionName)
						ifFalse: [releaseRep
								storeVersion: (trunkRep VERSIONNAMED: eachVersionInfo versionName)]]]

This is a nice sorting method. The problem is that it cannot tell the difference between these two things:

GraphicsTests-ar.29
GraphicsTests-ar.29.mcz

as one is a version name and the next a file name. #transferCurrentPackages winnows a collection of MCWorkingCopy instances
down to a collection of MCVersionInfo instances and then down to a list of version names. Just strings. At this point they need '.mcz'
appended to them. If not, when you feed them one at a time, #versionNamed: will return nil. Then you try to execute this:

releaseRep storeVersion: nil

and nothing happens. Insuring the '.mcz' suffix is added produces a collection of MCVersion instances, which can then be fed into
#storeVersion:.

I followed what #transferCurrentPackages was saying in a Workspace, debugging as I went.


</rant>


Post #10:


I just uploaded the initial 4.4 image.  It's 4.3 final without welcome
windows and now pointing to trunk for updates.

We're back to just one directory for 4.4 and I dropped the "alpha"
from the naming convention.  This is not only more tidy and neat, it's
more precise since it leaves just the update-number as the sole
indicator about the image.

We will not be troubling ourselves to post any "alpha" images with
major known bugs, but if we are really concerned about someone
downloading the latest alpha trunk image and slamming it into a
mission-critical production app prematurely only because they didn't
know it was alpha -- (yeah, right) then we could have a "disclaimer"
workspace.  But since the disclaimer is already spelled out in the
license, even that seems unnecessary.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120716/cba1479f/attachment.htm


More information about the Squeak-dev mailing list