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.8 -r1.9
--- openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml 26 Jan 2004 15:39:44 -0000 1.8
+++ openacs-4/packages/acs-core-docs/www/xml/releasing-openacs.xml 4 Feb 2004 16:47:34 -0000 1.9
@@ -1,5 +1,5 @@
-
@@ -46,19 +46,22 @@
cd /var/tmp/openacs-4
cvs tag -F openacs-5-0-0a1
- 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>".
-
+
+ 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
+
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
@@ -73,8 +76,8 @@
Go to a new working space and export the tagged files.
mkdir /var/tmp/tarball
cd /var/tmp/tarball
-cvs -d /cvsroot export -r openacs-5-0-0a1 acs-core
-
+cvs -d :pserver:anonymous@openacs.org:/cvsroot export -r openacs-5-0-0a1 acs-core
+mv openacs-4 openacs
Generate the tarball.
@@ -138,37 +141,42 @@
+
+ Here is a shell script that automates packaging the tarball:
+
+ release script missing
+
+ ($Id$)
+
+
+ How to Update the OpenACS.org repository
- Setup a local OpenACS server.
+ Setup a local OpenACS server running 5.0 or better.
- Edit the file packages/acs-admin/www/build-repository.tcl;
- Change the line with 'set head_channel' to '5-1' if the version on HEAD in the openacs.org cvs repository is 5.1. Etcetera.
- You may also want to change the line setting the variable 'repository_dir'.
-
+ 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.
+
+
+
- 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). Finally, it'll build another 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.
@@ -177,20 +185,14 @@
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.
+
-
-
- Here is a shell script that automates packaging the tarball:
-
-
- release script missing
-
- ($Id$)
-