Index: openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml,v
diff -u -r1.18 -r1.19
--- openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml 4 Jun 2004 13:54:03 -0000 1.18
+++ openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml 13 Jan 2005 13:55:16 -0000 1.19
@@ -19,6 +19,15 @@
+ Rebuild the Changelog
+ Rebuild the Changelog. I use a tool called cvs2cl. Run this command from the package root to automatically generate a Changelog file in the same dir. We generate two changelogs, one for the minor branch and one for the most recent release. The example below is for OpenACS 5.0.2:
+
+ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
+cvs2cl -F oacs-5-0 --delta openacs-5-0-0-final:oacs-5-0 -f ChangeLog
+cvs2cl -F oacs-5-0 --delta openacs-5-0-1-final:oacs-5-0 -f ChangeLog-recent
+
+
+
Update Version Numbers
The version numbers in the documentation and in the packages must be updated. This should only happen after a release candidate is approved.
@@ -41,7 +50,7 @@
Update /var/lib/aolserver/$OPENACS_SERVICE_NAME/readme.txt with the new version number
- Update version number in all of the core packages. Here's a bash/perl script which works but could be made easier to use. Run it from /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages:
+ Update version number and release date in all of the core packages. Here's a bash/perl script which works but could be made easier to use. (It depends on all of the old versions and dates being identical.) Run it from /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages:
#!/bin/sh
# run this file from ../packages to renumber all .info version numbers
@@ -61,26 +70,19 @@
perl -p -i -e 's/name="5\.0\.0"/name="5\.1\.0d1"/' $dir
perl -p -i -e 's/-5\.0\.0.apm"/-5\.1\.0d1.apm"/' $dir
perl -p -i -e 's/(provides.*version)="5\.0\.0"/\1="5\.1\.0d1"/' $dir
+ perl -p -i -e 's/2004-10-21/2004-11-26/' $dir
done
+ Install a new site using the modified code and verify that the automated tests pass.
+
+
Commit changes to CVS
- Rubuild the Changelog
- Rebuild the Changelog. I use a tool called cvs2cl. Run this command from the package root to automatically generate a Changelog file in the same dir:
-
- cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
-perl /var/tmp/cvs2cl/cvs2cl.pl -F oacs-5-0 --delta openacs-5-0-0-final:oacs-5-0
-
- Commit changes
-
-
-
-
Tag the files in CVS
The steps to this point should have ensured that the head of the current branch contains the full set of code to release. Now we need to tag it as the code to be released.
@@ -109,7 +111,7 @@
Branching
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
+ cvs tag -b oacs-5-0
If doing .LRN: Since the .LRN packages aren't all in one
module, we iterate through all of the modules. Log in first
@@ -124,7 +126,16 @@
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>".
+
+ Apply the final tag across the tree. First, check out the entire OpenACS tree, getting the most recent stable version of each package. This is most simply done on openacs.org:
+ cd /var/tmp
+cvs -d /cvsroot checkout -r openacs-5-1-compat openacs-4
+cd openacs-4
+cvs tag openacs-5-1-2-final
+
+
+
@@ -221,7 +232,8 @@
Clean up after yourself.
cd /var/tmp
-rm -rf tarball dotlrn-tarball dotlrn-packages openacs-5.0.0a1
+rm -rf tarball dotlrn-tarball dotlrn-packages openacs-5.0.0a1
+rm -rf /var/tmp/openacs-4
@@ -233,8 +245,8 @@
($Id$)
-
- How to Update the OpenACS.org repository
+
+ How to Update the OpenACS.org repository
@@ -243,36 +255,36 @@
- Edit packages/acs-admin/www/apm/build-repository.tcl and adjust the Configuration Settings.
+ 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 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/".
+
+
+
- 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.
This is automated on OpenACS.org by having a dedicated site just for building the repository, invoked with this shell script. Since the page circumvents security checks for ease of use, the entire site is limited to local requests. The script is called daily with a cron job.
@@ -282,21 +294,21 @@
STATUS=`wget --output-document - http://127.0.0.1:8002/build-repository.tcl | grep DONE | wc -l`
if [ $STATUS -eq "1" ]
- then
+then
rm -rf /web/openacs.org/www/repository.old
mv /web/openacs.org/www/repository /web/openacs.org/www/repository.old
cp -r /web/repository/www/repository /web/openacs.org/www/repository
fi
-
-
- How to package and release an OpenACS Package
+
+
+ How to package and release an OpenACS Package
In this example, we are packaging and releasing myfirstpackage as version 1.0.0, which is compatible with OpenACS 5.0.x.
- Update the version number of your package in the APM.
+ Update the version number, release date, and package maturity of your package in the APM.
Make sure all changes are committed.
@@ -310,36 +322,82 @@
Done. The package will be added to the repository automatically. If the correct version does not show up within 24 hours, ask for help on the OpenACS.org development forum.
-
-
-
-
- How to Update the translations
-
+
+
+
+
+ How to Update the translations
+
+
+ Identify any new locales that have been created.
+ For each new locale, check the parameters, especially that
+ the locale is in the format [two-letter code for
+ language, lower-case]_[TWO-LETTER CODE FOR COUNTRY,
+ UPPER-CASE], and create a sql command. A
+ example sql command for creating a locale is:
+ insert into ad_locales
+ (locale, label, language, country, nls_language, nls_territory,
+ nls_charset, mime_charset, default_p, enabled_p)
+ values ('fa_IR', 'Farsi (IR)', 'fa', 'IR', 'FARSI', 'IRAN', 'AL24UTFFSS',
+ 'windows-1256', 't', 'f');
+ Put this command into the following four files. For the
+ upgrade files, the correct file name will depend on the
+ exact version.
+
-
- 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.
-
- This approach puts the translation server at risk. An alternate approach would be to create a whole new checkout on the appropriate branch (such as oacs-5-0), point that at the live production database, import keys (which is safe because keys on the translation server take precedence), then export keys back, and then commit. This gets the keys committed to the right branch without changing the code running on the production site. Updating the production site can then be a seperate exercise.
+ /packages/acs-lang/sql/postgresql/ad-locales.sql
- Go to ACS Lang admin page and click "Import All Messages"
+ /packages/acs-lang/sql/postgresql/upgrade/upgrade-current-version.sql
- Resolve conflicts, if any, on the provided page.
-
+ /packages/acs-lang/sql/oracle/ad-locales.sql
- Back on the admin page, click the export link. If there are conflicts, the messages will be exported anyway and any errors will be shown in the web interface.
+ /packages/acs-lang/sql/oracle/upgrade/upgrade-current-version.sql
-
- From the packages dir, 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
-
-
-
-
-
\ No newline at end of file
+
+
+
+
+ Make a backup of the production database. Restore it as a new database. For example, if upgrading from OpenACS 5.1.1, and the site name/database name is translate-511, create translate-512b1.
+
+
+ Check out the latest code on the release branch (e.g., oacs-5-1) as a new site, using the new site name (e.g., /var/lib/aolserver/translate-512b1. Copy over any local settings - usually, /etc/config.tcl and /etc/daemontools/run and modify appropriately. Also, copy over several translation-server-only files:
+ ...TBD
+
+
+
+
+ Shut down the production site and put up a notice (no procedure on how to do this yet.)
+
+
+ Start the new site, and upgrade it.
+
+
+ Go to ACS Lang admin page and click "Import All Messages"
+
+
+ Resolve conflicts, if any, on the provided page.
+
+
+
+ Back on the admin page, click the export link. If there are conflicts, the messages will be exported anyway and any errors will be shown in the web interface.
+
+
+ Commit the message catalogs to cvs.
+
+
+ From the packages dir, 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
+
+
+ If everything went well, reconfigure the new site to take over the role of the old site (/etc/config.tcl and /etc/daemontools/run). Otherwise, bring the old site back up while investigating problems, and then repeat.
+
+
+
+
+
\ No newline at end of file