%myvars; ]> Update documentation version numbers: Update /packages/acs-core-docs/www/xml/variables.ent with the new version number. Add new section in /packages/acs-core-docs/www/xml/for-everyone/release-notes.xml Regenerate all HTML docs Update /readme.txt with the new version number Rebuild the Changelog. Using cvs2cl: perl /var/tmp/cvs2cl/cvs2cl.pl -F oacs-5-0 --delta openacs-5-0-0-final:oacs-5-0 Commit changes Check out the whole cvs tree. The files must be checked out through a cvs account with write access and should be a checkout from the release branch. In this example, we are assuming this is being done as a local user on openacs.org (which make the checkout and tagging operations much faster). cd /var/tmp cvs -d /cvsroot checkout -r oacs-5-0 openacs-core Repeat with the dotlrn cvs tree. cd /var/tmp mkdir dotlrn-packages cd dotlrn-packages cvs -d /dotlrn-cvsroot checkout -r dotlrn-2-0 dotlrn-all Tag the tree. cd /var/tmp/openacs-4 cvs tag -F openacs-5-0-0a1 When we feature-freeze on HEAD as part of the release process, we are blocking new development. To avoid this, we branch the code at this point, so that new work can continue on HEAD while the branch is stabilized for release. However, branching means that bug fixes have to be synchronized between HEAD and the branch, and bug fixes tend to be more frequent right at this time. Therefore, our actual branch point is as late as possible - essentially, we do not branch until and unless new feature work is actively blocked by the feature freeze. Branching is almost the same as tagging, except for the flag and slightly different tag nomenclature. To see the list of old branches, cvs status -v somefile. cvs tag -b oacs-5-0 Tag dotLRN. Since the dotLRN packages aren't all in one module, we iterate through all of the modules. Log in first (cvs login) so that you don't have to log in for each module. cd /var/tmp/dotlrn-packages for dir in *; do ( cd $dir && cvs tag -F dotlrn-2-0-0a1 ); done Note that we use the -F flag which will force the tag to the new version (just in case someone has created the tag already on another version). Excercise care when doing this since you don't want to inadvertently move a prior release tag. Also if the tagging goes horribly wrong for some reason you can delete the tag via "cvs tag -d <symbolic_tag>". Make the tarball Go to a new working space and export the tagged files. mkdir /var/tmp/tarball cd /var/tmp/tarball cvs -d :pserver:anonymous@openacs.org:/cvsroot export -r openacs-5-0-0a1 acs-core mv openacs-4 openacs Generate the tarball. cd /var/tmp/tarball mv openacs-4 openacs-5.0.0a1 tar cz -f openacs-5.0.0a1.tar.gz openacs-5.0.0a1 Go to a new working space and export the tagged files. (was getting errors here trying to use -d, so gave up and just moved things from openacs-4 to openacs at the end) mkdir /var/tmp/dotlrn-tarball cd /var/tmp/dotlrn-tarball cvs -d /cvsroot export -r openacs-5-0-0a1 acs-core cd /var/tmp/dotlrn-tarball/openacs-4/packages cvs -d /cvsroot export -r openacs-5-0-0a1 dotlrn-prereq cvs -d /dotlrn-cvsroot export -r dotlrn-2-0-0a1 dotlrn-core Copy the dotlrn install.xml file, which controls which packages are installed on setup, to the root location: cp /var/tmp/dotlrn-tarball/openacs-4/packages/dotlrn/install.xml \ /var/tmp/dotlrn-tarball/openacs-4 Generate the tarball cd /var/tmp/dotlrn-tarball mv openacs-4 dotlrn-2.0.0a1 tar cz -f dotlrn-2.0.0a1.tar.gz dotlrn-2.0.0a1 Test the new tarball Update openacs.org frontpage, bug-tracker versions, project page, etc. Clean up after yourself. cd /var/tmp rm -rf tarball dotlrn-tarball dotlrn-packages openacs-5.0.0a1 Here is a shell script that automates packaging the tarball: release script missing ($Id: releasing-openacs.xml,v 1.12 2004/02/26 15:28:37 jeffd Exp $)

Setup a local OpenACS server running 5.0 or better. Edit packages/acs-admin/www/apm/build-repository.tcl and adjust the Configuration Settings. Request /acs-admin/apm/build-repository on your new server. The page will find all branches in the cvs repository labeled oacs-x-y, and build a repository channel for each of those branches where x>=5 (so not for 4.6 and earlier). It will also build a channel for HEAD, which will be named after what you set in 'head_channel' above. For each channel, it'll do an anonymous checkout of packges and contrib/packages, then build .apm files for each package in the checkout. The files will be stored on the server's hard drive in the directory specified by the 'repository_dir' variable in the page script, by default "[acs_root_dir]/www/repository/". If you're on openacs.org, everything should now be fine. Otherwise, you need to move the entire directory tree to openacs.org:/web/openacs/www/repository, replacing what was already there.

Update the translation server. (Approach 1: upgrade to the last release; approach 2: upgrade to head or to an alpha or beta release.) Use CVS up. Go to ACS Lang admin page and click "Import All Messages" Resolve conflicts, if any, on the provided page, if any. Back on the admin page, click the export link. If there are conflicts, the messages will be exported anyway and errors will be shown. Run the acs-lang/bin/check-catalog.sh script. (This checks for keys no longer in use and some other things. Until it is rolled into the UI, do it manually and check the results and take whatever steps you can intuit you should do.) CVS commit the catalog files. Done