Kepler Release Process

This is currently smashed together from an old cheatsheet, memory, and old commit messages.

This is not authoritative, comprehensive, or error-free. Please update and improve this as this you go through the process.

Kepler Release Process

It's important to note what branches make up the last release, and what branches will go into the new release. Maintaining these two lists in text files in front of you as you go can be very helpful.

Pre-branch Checklist

* Identify the differences of the current Kepler trunk from last release version. Main differences include jar license, java source, new actors, actor changes. diff is a good tool for it: diff -r --exclude=".svn" --exclude="target" --exclude=".classpath" --exclude=".project" TrunkModulePath LastBranchModulePath

* check source has license headers. In the past I've utilized dry-run of update-copyright to identify files. I did not trust update-copyright enough to actually use it:

ant update-copyright -DdryRun=true -DcopyrightFile=copyright.txt -DcopyrightYear=2012 | grep -B1 "This file does not contain a copyright">  ~/missing_copyrights.txt

* check files' svn:keywords are all set properly

* open all demo workflows and close. any workflows that prompt you to save when closing should be saved/exported so that Kepler does not prompt the user to save unless changes are made. 

Documents

'User Manual' and 'Getting Started Guide'

1. ideally updating screenshots showing outdated UI.

2. updated documents need to be checked in both working and shipping directories of kepler-docs svn (https://code.kepler-project.org/code/kepler-docs/trunk/outreach/documentation) and common module in kepler svn (https://code.kepler-project.org/code/kepler/trunk/modules/common/configs/ptolemy/configs/kepler)

Others

* make any necessary updates to build-area-2.X/README.txt

* make any necessary updates to common-2.X/configs/ptolemy/configs/kepler/intro.htm

* update all contributors lists. Eventually elimintate dupes and maintain only one:

** common's configs/ptolemy/configs/kepler/doc-index.htm

** #

** in documentation somewhere?

** somewhere else?

  The following can be used to get a list of users that have made commits to the svn repository:

  svn log https://code.kepler-project.org/code/kepler/trunk --quiet | awk '/^r/ {print $3}' | sort -u

* update license.txt files with date and any new libraries (e.g. jars). Ensure any new library licenses do not conflict w/ ours.

  The copyright year at the top of <module>/module-info/licenses.txt can be updated using sed:

  sed -i licenses.txt.bak '1,/2012/s/2012/2013/'  <module>/module-info/licenses.txt

* remove non-ascii characters in license.txt files

  perl -pi -e 's/[[:^ascii:]]//g' licenses.txt

* if a non-ascii character was removed after Copyright, use the following to add (c):

  sed -e 's/Copyright[^0-9]*/Copyright (c) /g' -i "" licenses.txt

* update common's copyright file: configs/ptolemy/configs/kepler/copyright.htm

* update version for splash screen in: common/resources/configurations/configuration.xml

  <kepler>

    <version>X.Y</version>

  </kepler>

    * common-2.4/configs/ptolemy/configs/kepler/UserManual.pdf

Create new branches as necessary here: https://code.kepler-project.org/code/kepler/releases/release-branches/ using SVN copy, copying modules from trunk.

Modify branches' modules.txt files to refer to branch versions:

module-manager-gui-2.X/module-info/modules.txt

kepler-2.X/module-info/modules.txt

build-area/module-manager-gui.txt

Modify the iconFile item based on the new common directory name at build-area/resources/installer/windows/shortcut.ftl

# Depending on the state of test-area, you *might* want to simply delete it and start fresh. Think this through, and check no one else is using it before you delete it. There's no guarantee the last person left the test-area in a state that reflects exactly what was released (though chances are good).

To see differences between test-releases and released modules:

svn ls https://code.kepler-project.org/code/kepler/releases/released/ > released.txt

svn ls https://code.kepler-project.org/code/kepler/releases/test-releases/ > test-releases.txt

$ svn delete https://code.kepler-project.org/code/kepler/releases/test-releases

$ svn copy https://code.kepler-project.org/code/kepler/releases/released/ https://code.kepler-project.org/code/kepler/releases/test-releases/

Ptolemy

svn cp https://code.kepler-project.org/code/kepler/trunk/modules/ptolemy https://code.kepler-project.org/code/kepler/releases/release-branches/ptolemy-kepler-2.X

create kepler-2-X branch in ptII svn

in kepler-2-X branch in ptII svn, remove ptolemy/vendors, and directories listed in build-area/settings/ptolemy-excludes

edit kepler/module-info/modules.txt to use new ptolemy-kepler-2.X module and kepler-2.X branch:

ptolemy-kepler-2.X https://source.eecs.berkeley.edu/svn/chess/ptII/branches/kepler-2-X

JAR modules

$ cd kepler.modules/build-area;

$ ant change-to -Dsuite=kepler; svn update; ant update; ant clean-all;

# verify you have no local changes.

$ cd ..; svn stat -u *;

# *** Each time before you jar and release/patch, first delete remaining release-area folder, to ensure these items get recreated. ***

rm -rf kepler.modules/release-area;

# Before patch/release edit the module's modules.txt by hand to include caret (does this have to come before ant jar?)

ant jar;

# publish each patch/release to test area.

# Be sure to use -Dsuite or -Dmodule as appropriate. There are some oddities here with unexpected modules being considered suites. Check previous release.

If the module contains a module-info/modules.txt, make sure the modules listed in there use version numbers, and release with, e.g.:

ant release -Dtest=true -Dsuite=module-manager-gui-2.4

For Kepler 2.4, kepler-2.4 and module-manager-gui-2.4 have module-info/modules.txt.

If the module does not contain module-info/modules.txt, release with, e.g.:

ant release -Dtest=true -Dmodule=core-2.4

Release Candidates

# 11/21/11 this is how i do an RC:

# don't know if you can change-to a test area

# so change to kepler, where module-manager-gui's configuration.xml has been modified to point at test-area: https://code.kepler-project.org/code/kepler/releases/test-releases/

# and checkout test-release kepler-2.Y.0 using gui MM

$ ant change-to -Dsuite=kepler

$ ant run

# accept patches, then quit kepler-2.X.0 after it comes up

# fix current-suite.txt by hand, change:

kepler-2.X.^ to kepler-2.X.0

# fix modules.txt by hand:

cp ../kepler-2.X.0/modules-info/modules.txt modules.txt

# remove any junk:

rm rollback.txt rollback-current-suite.txt

svn stat -u (check no cruft hanging around)

# make sure have a few gigs free space

# make sure you're on a mac; mac installer needs hdiutil to be built

ant make-installers -Dversion=2.X

Testing Release Candidates

# opening and running all demos

# construct and run your own simple workflow

# export to xml

# save and save as kar

# upload and download of workflow kars

# Data search and use

# headless testing

# changing back and forth between suites and versions, make sure menu's don't get messed up

# open kars built in other versions and suites, both GUI and command line

# getting patches

# make sure help menus work and text is updated

# kar module dependency and strictness - e.g. opening a kar that needs other modules

Misc Notes

Be aware people occasionally commit fixes to release branches, but do not issue patches. This means the patch you're about to release may contain more than you expect. Perhaps it even relies on another unreleased patch.