OpenACS Core and .LRN
- Update version numbers:
+
+ Update Translations
+
+
+
+
+
+ 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.
+
+ .LRN: this must be repeated for .LRN modules (dotlrn-core in the dotlrn cvs tree) and for any modified modules in the .LRN prerequisites (dotlrn-prereq in openacs cvs tree). My current working model is that I bulk-update .LRN and OpenACS core but that I don't touch dotlrn-prereq modules - I just use the most recent release and it's up to individual package developers to tag and release those packages when they change. This model is already broken because following it means that dotlrn-prereqs don't get new translations.
- Update /packages/acs-core-docs/www/xml/variables.ent with the new version number.
+ Update /var/lib/aolserver/service0/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
+ Add new section in /var/lib/aolserver/service0/packages/acs-core-docs/www/xml/for-everyone/release-notes.xml
Regenerate all HTML docs
+ cd /var/lib/aolserver/service0/packages/acs-core-docs/www/xml
+make
- Update /readme.txt with the new version number
+ Update /var/lib/aolserver/service0/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 the tarball root:
+ 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/service0/packages:#!/bin/sh
# run this file from ../packages to renumber all .info version numbers
@@ -51,27 +63,37 @@
perl -p -i -e 's/(provides.*version)="5\.0\.0"/\1="5\.1\.0d1"/' $dir
done
-
- 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/log/aolserver/service0
-perl /var/tmp/cvs2cl/cvs2cl.pl -F oacs-5-0 --delta openacs-5-0-0-final:oacs-5-0
+
+ Commit changes to CVS
-
-
- Commit changes
-
-
- Check out OpenACS Core. The files must be checked
+
+ 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/service0
+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.
+
+
+
+ Check out OpenACS Core. 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 acs-core
- Repeat with the dotlrn cvs tree.
+ If doing .LRN, repeat with the dotlrn cvs tree.cd /var/tmp
mkdir dotlrn-packages
cd dotlrn-packages
@@ -89,20 +111,26 @@
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
+ If doing .LRN: Since the .LRN 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
+for dir in *; do ( cd $dir && cvs tag dotlrn-2-0-2-final ); done
+for dir in *; do ( cd $dir && cvs tag -F openacs-5-0-compat ); done
- Note that we use the -F flag which will force the tag to the new version (just in
+ Note that for the compat tag 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
+
+ Make the tarball(s)
+
+
@@ -166,20 +194,39 @@
- Test the new tarball
+
+ Test the new tarball(s)
+ Download the tarballs just created and install them and make sure everything looks okay and that automated tests pass.
+
- Update openacs.org frontpage, bug-tracker versions, project page, etc.
+
+ Update Web site
+ Update the different places on OpenACS.org where we track status.
+
+
+ Release Status for the current version - something like http://openacs.org/projects/openacs/5.0/milestones
+
+
+ Home page of openacs.org
+
+
+ Post a new news item
+
+
- Clean up after yourself.
+
+ Clean Up
+ 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:
+ Here is a shell script that automates packaging the tarball (it's a bit out of date with the new steps - I've been doing everything manually or with little throwaway scripts as detailed above until the process is stabilized).
release script missing
@@ -236,7 +283,7 @@
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 packages in the APM.
+ Update the version number of your package in the APM.Make sure all changes are committed.
@@ -260,20 +307,20 @@
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.Go to ACS Lang admin page and click "Import All Messages"
- Resolve conflicts, if any, on the provided page, if any.
+ 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 errors will be shown.
+ 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.
-
- 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.)
+ 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.)