Release Process

From Einstein Toolkit Documentation
Jump to: navigation, search

Release Process

This page describes the release process in some detail. Getting a release out of the door without embarrassing oversights requires a bit more planning and care than one would like.

TODO: reformat this page as a checklist which can be marked up for each release as each item is addressed

Long-term planning

A few months or weeks before the release:

  • Decide it is time to make another release
  • Choose features which are going to be included, and those which won't be included
  • Choose a tentative date
  • Begin discussions on the mailing list, reminding people to look at test cases, review patches etc.

One or two weeks before the release

RH One or two weeks before the release seems much too late to review thorns for quality, docs, test-cases, and to decide on release critical systems. I would have expected this to have to happen at least a month before the release.

  • Set up a wiki planning page for the release
  • Ask for volunteers, assign tasks to people
  • Review thorns for code quality, documentation, test cases
  • Decide on a thorn list
  • Decide on a list of release-critical systems
  • Collect list of new features, newsworthy items, and acknowledgements for release announcement on wiki
  • verify that gallery runs and example parfiles still work with new release
  • Choose a concrete date
  • Announce date publicly

One or two days before the release

  • Have a telecon with the release team, discuss (and modify if necessary) release process and responsibilities
  • Get a list of all repositories that are involved (including repositories for tools such as GetComponents)
  • Publicly declare a freeze on all involved thorns and tools
  • Ensure that any manually-generated files are consistent (i.e. regenerate McLachlan, WeylScal4 and EinsteinExact from their source with the current version of Kranc, generate the Cactus autoconf script, the Cactus loop macros etc)
  • Test all thorns on all systems, collect status reports on wiki
  • verify that new users tutorial still works
  • Update release planning wiki page with peoples', thorns', and systems' statuses
  • Set up a (smaller) technical release team who will be available all day on the day of the release
  • Draft release announcement

The release

  • Have the technical release team meet in the same room (brick, EVO, chat, phone)
  • Briefly re-check status of thorns and machines
  • Possibly disable all outside write access to all critical repositories
  • * cvs: ???
  • * svn: svn copy https://<repository-server>/<repository-path>/trunk https://<repository-server>/<repository-path>/branches/ET_2011_05
  • * darcs: clone the repository, appending a suffix to the name
  • * git: git push origin origin:refs/heads/ET_2011_05
  • * hg: ???
  • Possibly update version numbers in stable/development branches
  • Update component lists to point to new stable version
  • Check out release branch on all systems, re-run all quick tests
  • Update documentation on web sites (set up fresh copies of pdfs/htmls)
  • Update tutorials on web sites (update version numbers, urls)
  • Re-enable write access to all repositories
  • Finalise release announcement
  • ANNOUNCE:, {news|users}, Jennifer Claudet <> for AllCCT,,, HPCWire

After the release

  • Watch mailing lists for problem reports
  • Use released version to repeat a few production simulations
  • Update this page with new lessons learned

Helpful Tools

This section collects a handful of useful commands that may become critical to guarantee the quality of the release. The descriptions below are quite technical and intended for the developers and maintainers only.

Technical Details


ThornGuide.php is in /www/einstein/www/documentation

It draws on the autogenerated http doc files, which are found here:


Possible installation strategy to be followed when a new release is available.

cd /var/www/einstein
curl -kLO
tar xzf HTML.tar.gz
mv documentation old.documentation
mv HTML documentation
# check that everything looks good
rm -fr old.documentation

Other stuff

Create new docs in about/releases/
Create the announcement in media/news/recent.php and associated links.
Visit to make the change live.
News announcement to,,,
Post to Ad, news on
Post announcement to the Einstein Toolkit Facebook page.
Update and commit the changes to the thornlist in the manifest
Create the git tags and branches: ET_2018_02_v0, Cactus_4.4.0
   in each git repo:
       git tag ET_2018_02_v0; git push origin ET_2018_02_v0
       git checkout -b ET_2018_02; git push origin ET_2018_02
   use "git fetch -t" to get the latest tags.
Create svn tags and branches
 for i in BLAS LORENE GSL PETSc LAPACK FFTW3 pciutils  hwloc OpenBLAS MPI OpenCL HDF5 PAPI zlib libjpeg
     cd /home/sbrandt/cactus/Cactus/arrangements/ExternalLibraries/$i
     svn copy$i/trunk \$i/tags/ET_2018_02_v0 \
         -m "Tagging release ET_2018_02"
for i in BLAS LORENE GSL PETSc LAPACK FFTW3 pciutils  hwloc OpenBLAS MPI OpenCL HDF5 PAPI zlib libjpeg
    cd /home/sbrandt/cactus/Cactus/arrangements/ExternalLibraries/$i
    svn copy$i/trunk \$i/branches/ET_2018_02 \
        -m "New branch for release ET_2018_02"

Creating and working with git branches

Some basic git commands to create and work with branches:

Check in your local repository which branch you are in:

%git branch
* master

Check the branches of your project in the remote repository:

%git branch -r

Create a new branch called test:

%git checkout -b test
Switched to a new branch "test"
%git branch  
* test

Work on files in that branch:

%vi test.txt

Verify the status of files you modified in that branch:

%git status
 # On branch test
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #       test.txt
 nothing added to commit but untracked files present (use "git add" to track)

Add the file(s) edited to the git stage area:

%git add test.txt
%git status
 # On branch test
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #       new file:   test.txt

Commit your changes to your local repository:

%git commit -m "test file only"
 Created commit 14644af: test file only
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 test.txt

Now you want to push these changes to a remote repository that you have writing permission:

%git push origin test

Note however that, unless git is configured so, your local branch of "test" does not track any changes committed by others to the remote branch "test". Maybe the simplest way to proceed then is just to delete your local branch:

%git branch -D test
Deleted branch test.

and checkout the remote branch you just created but letting git know you want to track remote changes to that branch as well:

%git checkout --track -b test origin/test

You may want to see how two branches differ or how your modifications of the branch compare to the HEAD of the branch, for example. Suppose you just added the test.txt file to the staged git area called the index. To know the difference between the index and the HEAD, essentially what would be committed if 'git commit' is issued, just use git diff as follows:

%git diff  --cached
 diff --git a/test.txt b/test.txt
 new file mode 100644
 index 0000000..373c7b0
 --- /dev/null
 +++ b/test.txt
 @@ -0,0 +1 @@
 +Hello, world!