-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
+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.
.LRN: this must be +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 +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 +following it means that dotlrn-prereqs don't get new translations.
Update /var/lib/aolserver/$OPENACS_SERVICE_NAME/packages/acs-core-docs/www/xml/variables.ent @@ -61,10 +62,10 @@
-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 @@ -77,9 +78,9 @@ cvs -d /dotlrn-cvsroot checkout -r dotlrn-2-0 dotlrn-all
Tag the tree. If it's a final release of core, move or create -the appropriate openacs-major-minor-compat tag. (Ie, if releasing -5.0.3 final, move the openacs-5-0-compat flag.)
cd /var/tmp/openacs-4
+Tag the tree. If it's a final release of core, move or
+create the appropriate openacs-major-minor-compat tag. (Ie, if
+releasing 5.0.3 final, move the openacs-5-0-compat flag.)
cd /var/tmp/openacs-4
cvs tag -F openacs-5-0-0a1
cvs tag -F openacs-5-0-compat
@@ -97,15 +98,15 @@
somefile.
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 (cvs login) so
-that you don't have to log in for each module.
cd /var/tmp/dotlrn-packages
+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 dotlrn-2-0-2-final ); done
for dir in *; do ( cd $dir && cvs tag -F openacs-5-0-compat ); done
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. +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>".
@@ -162,25 +163,26 @@-Test the new tarball(s). Download the -tarballs just created and install them and make sure everything +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 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. Clean up after yourself.
cd /var/tmp
+Clean Up. Clean up after
+yourself.cd /var/tmp
rm -rf tarball dotlrn-tarball dotlrn-packages openacs-5.0.0a1
rm -rf /var/tmp/openacs-4
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).
+(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).#!/bin/bash # if TAG=1 create the cvs tags otherwise assume they exist. @@ -262,8 +264,8 @@ # Clean up after ourselves... cd $BASE && rm -rf dotlrn-tarball tarball openacs-4 dotlrn-packages -($Id: releasing-openacs.xml,v 1.22 2014/10/27 -16:39:30 victorg Exp $)+