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: docs/tutorial, docs/xsd and generated html in the following dirs docs/doxygen, docs/pydoc, docs/wiki

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 two 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. 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. commit the changes
  3. 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")
  4. 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)
    4. upload source files (.tar.gz, .spec) to the opensuse build service
  5. make new sourceforge-release
    1. make a new release within the sumo package (named "version x.y.z")
    2. add files to the release
  6. inform the users about the new release
    1. add the change-log to the pages (http://sumo.sourceforge.net/wiki/index.php/ChangeLog)
    2. post information about the release to sumo-user@lists.sourceforge.net and sumo-announce@lists.sourceforge.net
    3. post information about the release to news
    4. post information into the blog
    5. patch the Downloads information also at Main_Page#Downloads and at the main index.html
  7. unpack the doc.tar.gz into the "release" folder on the web space
  8. tag all in the svn with a new version tag (includes fixing of tcpip revision), as follows 
> svn propedit svn:externals src/foreign/

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

> svn commit -m "tcpip revision fixed for 0.9.7 tagging" src/foreign/
> svn cp -m "tagging release 0.9.7" https://sumo.svn.sourceforge.net/svnroot/sumo/trunk https://sumo.svn.sourceforge.net/svnroot/sumo/tags/v0_9_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 and sumo.spec
  4. commit changes
  5. drink beer
This page was last modified on 9 September 2011, at 06:58.