Developer/HowToRelease

Packages

for an overview of created packages and contents see Downloads.

Release steps

Below, a list of steps that should be done in order to publish a new release is given. If the first four 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. check the calendar to update copyright statements
    4. update author information
  2. check the tests
    1. 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. recheck/rebuild the test networks (if necessary due to netconvert changes)
    3. recheck/rebuild the configuration schemata (if options were added)
  3. check the documentation
    1. update the change log
    2. update the download links to reflect the upcoming file paths
    3. generate options docu from config templates
  4. patch the version information
    1. in windows_config.h, also disable the HAVE_VERSION_H macro
    2. in configure.ac
    3. commit the changes
  5. 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")
  6. 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)
  7. 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
  8. 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
  9. unpack the doc.tar.gz into the "doc" folder on the web space
  10. 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. trac
    1. close the solved milestone tickets
    2. add new trac milestone if necessary
    3. close trac milestone retargeting open tickets
    4. add new version to trac

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 3 May 2013, at 10:30.