How to properly create a new .sources file
Last updated at 8:22 pm UTC on 17 March 2014
Traditionally, the sources file contains the source code for the base-classes while the changes contains changes and additions made by the Smalltalk user, in that image.
The desire for new releases is to deploy a condensed sources file and an empty changes file. "Condensed" in this case means it includes only the methods for the current release, plus the prior release, if the method changed for the current release.
To accomplish this, at the beginning of each release cycle, we use make a new alpha image for that release. Launch the just-released version of Squeak and, in a workspace, do it:
ReleaseBuilder prepareNextVersionAlpha
The system will prompt for the name of the new Squeak version and sources. Specify the sources name (without ".sources" on the end) for the next, e.g., the one beginning a new release cycle.
For example, if we are releasing Squeak 4.6, we would run #prepareNextVersionAlpha from the original Squeak4.5-13680 image. When the system asks for the version, specify Squeak4.6 and for the sources name, specify "SqueakV46".
The system will create file SqueakV46.sources in the current directory with the 4.5 version of each method (because we are at the very beginning of the release cycle, nothing has changed yet), and then prompt to save and exit the image. Close the window and save-and-exit immediately so that no further activity will be logged into the newly-created .changes file. Save it under the name, Squeak4.6-23456, where "23456" actually the update number of the image (available in Help | About).
Zip that .image, .changes, and .sources into a Squeak46-13680.zip and deploy it in the alpha directory at ftp.squeak.org.
For the 4.6 release, ReleaseBuilder will run #moveChanges, which will move current versions of all methods which changed during that dev cycle from the .changes file into the .sources file, leaving the .changes file empty once again.
A new .sources and .changes files are created in the current directory which must be included with the release.
This approach preserves changes from release-to-release, so a trail can possibly be followed as it would become necessary.
