OpenACS Core and .LRN

  1. Update Translations. the section called “How to Update the translations”

  2. 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.
    1. Update /var/lib/aolserver/service0/packages/acs-core-docs/www/xml/variables.ent with the new version number.

    2. Add new section in /var/lib/aolserver/service0/packages/acs-core-docs/www/xml/for-everyone/release-notes.xml

    3. Regenerate all HTML docs

      cd /var/lib/aolserver/service0/packages/acs-core-docs/www/xml
      make
    4. Update /var/lib/aolserver/service0/readme.txt with the new version number

    5. 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
      
      #---------------------------------------------------------------------
      # here's what we're looking for
      #---------------------------------------------------------------------
      #   <version name="5.1.0d1" url="http:blahblah/acs-kernel-5.1.0d1.apm">
      #      <provides url="acs-kernel" version="5.1.0d1"/>
      #---------------------------------------------------------------------
      # here's what we don't want to touch
      #---------------------------------------------------------------------
      #      <requires url="acs-kernel" version="5.0.0b4"/>
      #---------------------------------------------------------------------
      
      for dir in `find -name *.info`
        do
        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
      done
    6. Commit changes to CVS

  3. 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

  4. 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.

    1. 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

      If doing .LRN, 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
      
    2. 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
      

      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

      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. Also if the tagging goes horribly wrong for some reason you can delete the tag via "cvs tag -d <symbolic_tag>".

  5. Make the tarball(s). 

    • openacs-core. 

      1. 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
      2. 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
        
    • dotlrn. 

      1. 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
        
      2. 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
        
      3. 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
        
  6. Test the new tarball(s). Download the tarballs just created and install them and make sure everything looks okay and that automated tests pass.

  7. 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

  8. 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 (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.
TAG=1

# What release version are we building; version format should be
# dashes rather than dots eg. OACS_VERSION=5-0-0b4

OACS_VERSION=5-0-0b4
DOTLRN_VERSION=2-0-0b4

OACS_BRANCH=oacs-5-0
DOTLRN_BRANCH=dotlrn-2-0

DOTLRN_CVSROOT=/dotlrn-cvsroot
OACS_CVSROOT=/cvsroot

#
# Nothing below here should need to change...
#
BASE=/var/tmp/release-$OACS_VERSION
mkdir $BASE
if [ ! -d $BASE ]; then 
    echo "Failed creating base dir $BASE"
    exit 1
fi

cd $BASE 

if [ $TAG -eq 1 ]; then 

    # Checkout and tag the release 
    cvs -d $OACS_CVSROOT checkout -r $OACS_BRANCH openacs-4
    cd openacs-4 
    cvs tag -F openacs-$OACS_VERSION 
    cd ../


    # Checkout and tag the dotlrn release
    mkdir dotlrn-packages
    cd dotlrn-packages
    cvs -d $DOTLRN_CVSROOT checkout -r $DOTLRN_BRANCH dotlrn-all
    for dir in *; do ( cd $dir && cvs tag -F dotlrn-$DOTLRN_VERSION ); done
    cd ../

    #
    # Should check for .sql .xql .adp .tcl .html .xml executable files and squak if found.
    #

fi



# Generate tarballs...
#

# openacs
#
mkdir tarball
cd tarball
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION acs-core
mv opeancs-4 openacs-${OACS_VERSION//-/.}
tar -czf ../openacs-${OACS_VERSION//-/.}.tar.gz openacs-${OACS_VERSION//-/.}
cd ..

# dotlrn
#
mkdir dotlrn-tarball
cd dotlrn-tarball
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION acs-core
cd  openacs-4/packages
cvs -d $OACS_CVSROOT export -r openacs-$OACS_VERSION dotlrn-prereq
cvs -d $DOTLRN_CVSROOT export -r dotlrn-$DOTLRN_VERSION dotlrn-core
cd ../..
cp -f openacs-4/packages/dotlrn/install.xml openacs-4
mv openacs-4 dotlrn-${DOTLRN_VERSION//-/.}
tar -czf ../dotlrn-${DOTLRN_VERSION//-/.}.tar.gz dotlrn-${DOTLRN_VERSION//-/.}


# Clean up after ourselves...
cd $BASE && rm -rf dotlrn-tarball tarball openacs-4 dotlrn-packages
($Id: releasing-openacs-core.html,v 1.5 2004/04/21 09:49:43 joela Exp $)
View comments on this page at openacs.org