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. All necessary commits which have no ticket of their own may refer to ticket *563.

Merge phase
Major changes to the SUMO trunk should end about two weeks before the release data. This refers especially to merges of project branches into the trunk.

Freeze phase (Release day - 7)

 * check the sources
 * compile, try to remove warnings and commit the patches
 * run AStyle and commit changed files
 * check the calendar to update copyright statements
 * check whether traci version needs to be incremented and rebuild traci constants in python (tools/traci/rebuildConstants.py)
 * update author information
 * check the regular tests
 * put special attention to the tests which serve as examples, see tests/examples.txt!
 * Win32 and gcc4_64 should have no failing tests, the other platforms are less important
 * If there are failing tests, which are not flagged as known bugs, save them after careful checking or open a ticket and assign a known bug.
 * recheck/rebuild the test networks (if necessary due to netconvert changes)
 * check the tests again
 * check the documentation
 * update the change log
 * generate options docu from config templates using tools/docs/configTemplateToWiki.py
 * recheck/rebuild the configuration schemata (if options were added) using tools/xml/rebuildSchemata.py
 * check the internal tests (same procedure as above) and the Planet SUMO scenarios
 * trac
 * add new trac milestone if necessary
 * add new version to trac
 * check all remaining tickets and assign them to later milestones or to persons.

The trunk is now frozen. All commits which do not refer to an open ticket for the upcoming release need to be made to a separate branch. The freeze phase should not last longer than one week. The goal is to fix all scenarios and have all failing tests fixed, which are not assigned to a later milestone.

Release day - 1
All scenarios should be fixed by now.
 * patch the version information
 * in windows_config.h, also disable the HAVE_VERSION_H macro
 * in configure.ac and build/sumo.wxs
 * commit the changes
 * check the documentation
 * update the change log again if necessary
 * update the Downloads links to reflect the upcoming file paths

Release day
The nightly build should have generated all releasable packages. If not, delay the release. (The complete documentation, tests and source distribution build can be achieved via "make dist-complete".) The following things need to be there: If everything is fine: > 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.13.7 tagging" src/foreign/ tools/contributed/ > svn cp -m "tagging release 0.13.7" https://svn.code.sf.net/p/sumo/code/trunk https://svn.code.sf.net/p/sumo/code/tags/v0_13_7
 * the platform independent part of the distribution;
 * source distributions (.tar.gz, .zip) ("make dist", rename)
 * tests distributions (.tar.gz) ("make dist-tests")
 * docs distributions (.tar.gz) ("make dist-doc")
 * the binary part of the distribution
 * windows binary distribution (zip, includes docs)
 * windows installer (msi, Win32 and x64, includes docs)
 * check presence of RPMs on https://build.opensuse.org/package/show/home:behrisch/sumo
 * make new sourceforge-release
 * make a new folder in O:\Daten\Sumo\Releases
 * make a new release within the sumo package (named "version x.y.z")
 * add files to the release
 * update files at the opensuse build service
 * inform the users about the new release
 * post information about the release to sumo-user@lists.sourceforge.net and sumo-announce@lists.sourceforge.net
 * post information about the release to news
 * post information into the blog
 * patch the Downloads information also at Main_Page and at the main index.html
 * unpack the doc.tar.gz into the "doc" folder on the web space
 * change the current link for the docs
 * tag all in the svn with a new version tag (includes fixing of externals revision), as follows
 * trac
 * close trac milestone retargeting open tickets

After-release cleanup
The trunk is now open for changes again.
 * unfix tcpip revison, by removing the "-r" tag as mentioned above
 * reenable HAVE_VERSION_H in windows_config.h
 * rename version to "svn" in configure.ac
 * commit changes
 * drink your favorite beverage