Developer/HowToRelease

Contents

Packages

sumo-src-<VERSION>.tar.gz / sumo-src-<VERSION>.zip

  • base path is sumo-<VERSION>
  • result from make dist
  • shall contain: bin (.bat only), docs/tutorial, examples, build, src, tools, unittest

sumo-doc-<VERSION>.tar.gz

  • base path is sumo-<VERSION>
  • shall contain static HTML generated from the wiki (in docs), the tutorial sources (extracted from the tests) in docs/tutorial, schemata in docs/xsd and source documentation in docs/doxygen and docs/pydoc

sumo-tests-<VERSION>.tar.gz

  • base path is sumo-<VERSION>
  • shall contain the tests dir

sumo-winbin-<VERSION>.zip

  • base path is sumo-<VERSION>
  • shall contain: bin (.bat, .jar, .exe in Release version and dlls), everything from the doc.tar.gz, examples, tools

Release steps

Below, a list of steps that should be done in order to publish a new release is given. If the first three steps are done one day in advance one may skip the manual packaging and simply use the nightly files.

  1. check the sources
    1. compile, try to remove warnings and commit the patches
    2. run AStyle and commit changed files
    3. run the tests, check what fails, why and decide whether they're ok (put special attention to the tests which serve as examples, see tests/examples.txt!). If there are errors, patch tests or source accordingly and commit the changes.
  2. check the documentation
    1. update the change log
  3. patch the version information
    1. in windows_config.h, also disable the HAVE_VERSION_H macro
    2. in configure.ac
    3. in build/package/sumo.spec
    4. add entries to debian.changelog and sumo.changes
    5. commit the changes
  4. build the platform independent part of the distribution; For the impatient: The complete documentation, tests and source distribution build can be achieved via "make dist-complete".
    1. source distributions (.tar.gz, .zip) ("make dist", rename)
    2. tests distributions (.tar.gz) ("make dist-tests")
    3. docs distributions (.tar.gz) ("make dist-doc")
  5. build the binary part of the distribution
    1. recheck linux compilation with the source distribution
    2. use the source distribution for compilation under windows
    3. build windows binary distribution (zip, includes docs)
  6. make new sourceforge-release
    1. make a new release within the sumo package (named "version x.y.z")
    2. add files to the release
    3. update files at the opensuse build service
  7. inform the users about the new release
    1. post information about the release to sumo-user@lists.sourceforge.net and sumo-announce@lists.sourceforge.net
    2. post information about the release to news
    3. post information into the blog
    4. patch the Downloads information also at Main_Page#Downloads and at the main index.html
    5. patch the direct download link on the static front page
  8. unpack the doc.tar.gz into the "doc" folder on the web space
  9. tag all in the svn with a new version tag (includes fixing of externals revision), as follows 
> svn propedit svn:externals src/foreign/
> svn propedit svn:externals tools/contributed/

change to something like "tcpip -r123 https://shawn.svn.sourceforge.net/svnroot/shawn/src/apps/tcpip" 

> svn commit -m "external revisions fixed for 0.9.7 tagging" src/foreign/ tools/contributed/
> svn cp -m "tagging release 0.13.7" https://sumo.svn.sourceforge.net/svnroot/sumo/trunk https://sumo.svn.sourceforge.net/svnroot/sumo/tags/v0_13_7
  1. close trac milestone

After-release steps

Things to do after a release:

  1. unfix tcpip revison, by removing the "-r" tag as mentioned above
  2. reenable HAVE_VERSION_H in windows_config.h
  3. rename version to "svn" in configure.ac, sumo.spec, and sumo.dsc
  4. commit changes
  5. drink beer
This page was last modified on 11 November 2011, at 07:18.