[etoys-dev] [SVN][734] begin writing Documentation/Release-HowTo.txt

commits at etoys.squeak.org commits at etoys.squeak.org
Sun May 22 18:20:42 EDT 2011


Repository: http://etoys.squeak.org/svn

Revision: 734
Author:   bf
Date:     2011-05-22 22:20:40 +0000 (Sun, 22 May 2011)
Log Message:
-----------
begin writing Documentation/Release-HowTo.txt

Added Paths:
-----------
    trunk/Documentation/
    trunk/Documentation/Release-HowTo.txt

-------------- next part --------------
Added: trunk/Documentation/Release-HowTo.txt
===================================================================
--- trunk/Documentation/Release-HowTo.txt	2011-05-20 23:10:09 UTC (rev 733)
+++ trunk/Documentation/Release-HowTo.txt	2011-05-22 22:20:40 UTC (rev 734)
@@ -0,0 +1,80 @@
+HOW TO MAKE AN ETOYS RELEASE
+============================
+
+0. Code, Test, Debug, Commit
+----------------------------
+
+During regular development time, code is committed as Monticello
+packages to our main repository at
+
+    http://source.squeak.org/etoys/ 
+
+This repository is writable only by the Etoys core developers.
+Contributions by anyone are welcome in the "etoys-inbox" repository.
+
+Others can get these latest package versions using the "update code
+server" menu item in the "help" menu. First official updates are
+loaded, then it is offered to download the latest package versions.
+
+1. Prepare an update 
+--------------------
+
+The package versions for any (alpha/beta/final) Etoys release are fixed
+using a change-set pushed to the update stream at
+
+    http://etoys.squeak.org/updates/
+
+This change-set does not actually containing changes, but loads a
+Monticello configuration map as a Postscript. It can, however, also
+contain "do-its" for house-keeping (though this is rarely needed). Here
+is an example:
+
+    http://etoys.squeak.org/updates/2390repo1347-bf.cs
+
+The steps to create an update like this are:
+
+1. use the latest released version (e.g., a clean Etoys-To-Go)
+2. load updates, say yes to load the latest package versions
+3. in Monticello, browse the latest config, e.g. "update-bf.16"
+4. in the MC Config browser, choose "update from image". This will
+   record the updated versions in the config
+5. store the config in the local "etoys" repo, giving it a
+   new version name, e.g. "update-bf.17"
+6. display the change log from the previous config to this one:
+   `Utilities defaultRepositoryChangeLogOn: Transcript`
+7. create a new change set, naming it after the repo version shown at
+   the top of the change log, e.g. "repo3456-bf"
+8. paste the change log into the change set preamble, be careful to
+   replace all double quotes since this is a Smalltalk comment
+9. create the Postscript loading the config map as in the example
+   above. I usually copy the old postscript, delete the old package
+   list, and paste in the new one from the config just stored.
+   (for easier copy-and-paste, store the config map in the local
+   package cache)
+10. save the change set, and broadcast it to the update stream using
+   the FileList tool.
+   
+If testing shows that more changes are needed, then commit fixes using
+Monticello, and store a new update map. Each update map should be
+published as change set, too.
+
+2. Create the release image
+----------------------------
+
+_to be written_
+
+3. Update projects, translations, etc.
+--------------------------------------
+
+_to be written_
+
+4. Build installers
+-------------------
+
+### Windows
+
+### Mac
+
+### Linux
+
+### Etoys-To-Go


More information about the etoys-dev mailing list