Release Management

This page describes how we release software.

The following pages might be of use:

  • Development Tree
  • Testing
  • Building a release

    Splitting the tree

    1. Add any new models to $PTII/ptolemy/configs/doc/completeDemos.htm
    2. If necessary create applets for new demos
      cd $PTII/ptolemy/domains/wireless/demo/SmartParking
      $PTII/bin/copernicus -codeGenerator applet -targetPath ptolemy/domains/wireless/demo/SmartParking SmartParking.xml
      
      Then add the .htm files to the makefile.
      Note that sometimes we use just the Vergil applet, in which case we do
      mv FooVergilApplet.htm FooApplet.htm
      
    3. Ptolemy handled about:copyright URLS specially. One facility on the copyrigth page is the ability to expand all the model, .html files and .pdf files on the various demonstration pages. This allows us to verify that all the resources are present in the tree.
      Following the links on about:copyright is an essential part of testing each release.
      For details, see actor.gui.GenerateCopyrights and actor.gui.HTMLViewer
    4. Ptolemy II is organized in to jar files, where each directory contains a jar file of the .class files and another resources that are necessary for that package. These resources include files like images and pdfs. Parent directories contain the jar files in children directories.
      When building a release, it is usually best to build the Web Start release first because it is easier to change one jar file and retry something in Web Start than it is to rebuild an entire Windows installer.
      Use about:copyright to test the Web Start release.
    5. Clean the tree by running make checkjunk and adding files as appropriate to the makefiles
    6. Run $PTII/util/testsuite/chkjava on the java files and fix problems
    7. Run Jalopy to add curly brackets around single statement if, while and other statements:
      Wrong:
      if (foo == bar) 
          return; 
      
      Right:
      if (foo == bar) {
          return; 
      }
      
      The reason this is important is because if one does
      if (foo == bar) 
          System.out.println("About to return");
          return; 
      
      then the return is not part of the if statement.

      We indent using Jalopy to add braces and then reindent using jindent to get the indentation right.

      To set up Jalopy:

      1. Download the console version from http://jalopy.sourceforge.net/download.html
      2. Create a directory to unzip the download into and unzip it.
        Note: the zip file will create directories like bin, docs and lib in the current directory, so be sure to unzip it inside an empty directory.
        See also http://jalopy.sourceforge.net/plugin-console.html
      3. Run bin/preferences.sh
        If you get
        c:/Program: not found
           
        You may need to edit bin/preferences.sh and put double quotes around JAVACMD in the last line:
        "$JAVACMD" -classpath "$LOCALCLASSPATH" de.hunsicker.jalopy.swing.SettingsDialog
           
      4. Note that under Windows, the settings are stored in c:/Documents and Settings/username/.jalopy
        If things get confusing, you may want to remove that directory and start bin/preferences.sh over again
      5. In the "Jalopy Settings" window, under Printer -> Braces -> Misc, click all the boxes in the Insert braces section
      6. Change the continuation indent to 8 characters: under Indentation -> Sizes, change the continuation indent to 8 characters.
      7. Disable sorting: under Printer -> Sorting -> Declarations, uncheck "Sort class elements"
        If sorting is not disabled, then the fields will be before the methods
      8. Change the wrapping so we wrap before operators: under Printer -> Wrapping, in the Policy section, select "Wrap before operators". Also, note that the line length should be 80 characters so that when we print out the software for review, the lines print properly.
      9. Close the Jalopy Settings window, you are now ready to indent. From within Eclipse, to format using Jalopy, go to the Java view, open a file, right click and select "Format with Jalopy". The keyboard short cut is Ctrl+Alt+F10.

      Create a list of java files with:
      # Check out a clean tree
      # Make sure empty directories are removed
      cvs update -P -d
      cd ptII
      adm/bin/ptIItxtfiles > /tmp/f
      egrep '*.java$' /tmp/f | grep -v /vendors/ >& /tmp/j
      # Edit /tmp/j and removed the derived files created by the parser
      #   in data/expr
      # Remove:
      #   Everything in ct/demo/corba/util
      #   ./ptolemy/data/unit/UParserConstants.java
      #   ./ptolemy/data/unit/UParser.java
      #   ./ptolemy/data/unit/UParserTokenManager.java
      
    8. Add trailing newlines to files with $PTII/adm/bin/addtrailingnl
    9. On a Unix box, check for files with control-Ms:
      cat /tmp/f | xargs $PTII/util/testsuite/controlm
      
      Use dos2unix to fix the files.
      Also, check that text files that have control-ms are not checked in to cvs with -kb:
      cat /tmp/f | xargs cvs status >& /tmp/cv.out
      
      Then search /tmp/cv.out for -kb
    10. Run $PTII/util/testsuite/jindent on the java files and indent the files to the Ptolemy II coding standard.
      When you run jindent, watch out for files that have the entire class body indented. If the class comment contains the word "extends" or "implements" then emacs sometimes indents the "public class" and the rest of the body. Search the output for "public class" and carefully examine any files where public class has leanding spaces.
    11. Run $PTII/adm/copyright/fixcopyrights (not shipped with the release) and update the copyrights on the .java, .tcl and makefiles
    12. Run $PTII/adm/copyright/fixsince (not shipped with the release) and update the @since tags
    13. Run the nightly build, build a release and run $PTII/adm/copyright/chkcopyright on all the files.
      find . -type f -print > ~/tmp/ff
      sh ~ptII/adm/copyright/chkcopyright `cat ~/tmp/ff | grep -v .class | grep -v codeDoc | grep -v xml | grep -v alljtests.tcl | grep -v .htm | grep -v qcf | grep -v .dtd | grep -v gif`
      
    14. Concatenate all the javadoc files in to one file and run $PTII/util/testsuite/ptspell.
    15. Use Eclipse to fix the imports of the entire tree.
    16. Consider fixing other Eclipse warnings.
    17. Consider using GCJ: The GNU Compiler for Java to report unused variables and other problems. Note that GCJ3.4 will fail to compile awt and swing classes, but it is still worth getting the other error messages.
      cd $PTII make clean make -k JAVAC=gcj34 JFLAGS="-O2 -Wunused -Wextraneous-semicolon -Wno-deprecated -C" all >& make.out &
    18. Currently, we use Zerog's InstallAnywhere to build Windows installers. Building the Windows installer is fairly complex, below are some things to be aware of
    19. The Windows installer includes source files. These sources come from $PTII/adm/gen-N.M/ptIIN.M.src.jar. Obviously, this jar file should be created on a Windows machine so the end of line characters are Windows end of line characters.
    20. Tag the tree as the release tree and create a branch For more information about CVS, see the Gigascale CVS Pages

      To make a branch for 5.0-beta, use the following command:

      cd $PTII
      cvs tag -b rel-5-0-beta
      
      Then check out the release branch with
      cd ~/src
      cvs co -r rel-5-0-beta ptII
      mv ptII ptII5.0-beta
      
    21. The nightly build uses a makefile in ~ptII/adm (not shipped) to build the release. Copy the most recent makefile and set up a new tree for the release tree.

    Last Updated: $Date: 2005/05/02 20:30:17 $