How to Make a New Opus/UrbanSim Release
Making and Maintaing a Stable Release in Subversion
Much of the following information is based on the release branch description in the Subversion book.
Making a new stable release involves three steps: creating a release branch, finalizing it, and then tagging it as the zeroth bugfix of that major/minor release. After this, you maintain the release by fixing bugs as they are discovered, which leads to subsequent bugfix releases.
Making the Release Branch
So let's say that you're working on the trunk, which is at version 4.3-dev3216, i.e. working towards the 4.3 release. Once you feel the trunk is feature complete for 4.3, but perhaps needs some more rigorous testing before release, it is time to create the 4.3 release branch to allow the trunk to continue to have new features added to it.
To create the 4.3 release branch:
svn copy https://trondheim.cs.washington.edu/svn/opus/trunk \
https://trondheim.cs.washington.edu/svn/opus/branches/releases/4.3
At this point the trunk is for working towards the next release (in this example, 4.4), so you should edit opus_core/version_number.py to change the version to the new target.
Finalizing the Release Branch
You now can continue to squash bugs in the new release branch, without worrying about new features getting in the way. Of course, at this early stage, a bug in the release branch may represent a bug in the trunk, and vice versa, so you'll be spending some time porting bug fixes back and forth between them. Use whatever techniques you find easiest (e.g. svn merge, copy+paste, etc.)
Tagging the Release
Once you feel the new release is sufficiently stable, you can mark it as stable and tag it.
To mark it as stable, edit opus_core/version_number.py to change the stable variable to True and commit the change.
Then, to tag the release as the zeroth bugfix release, just do a copy of the release branch to the tags directory:
svn copy https://trondheim.cs.washington.edu/svn/opus/branches/releases/4.3
https://trondheim.cs.washington.edu/svn/opus/tags/4.3.0
Maintaining the Release
As bugs are found in the release, they can be fixed in the release branch, and then be tagged as a new bugfix release, e.g. 4.3.1:
svn copy https://trondheim.cs.washington.edu/svn/opus/branches/releases/4.3
https://trondheim.cs.washington.edu/svn/opus/tags/4.3.1
Making the Release Available to UrbanSim Users on the Website
Suppose that the new stable release is 4.3.2.
We provide two different ways to access stable releases: a zip file with some of the basic packages and the documentation, and a subversion tag. There is a CruiseControl build file in the opus_install project in cuspa that will make the zip file. To make the zip file, if necessary edit the build.xml script. You only need to do this if you are changing the major or minor release number, or adding more packages -- you don't need to change it to make a new bugfix release. Click the 'build' button on the CruiseControl webpage to create the zip file. The result will be under the 'artifacts' link on the webpage. Copy it and rename it appropriately, e.g. to opus-4-3-2.zip. Now create a new subdirectory for the release under /projects/urbansim5/www.urbansim.org/opus/releases, called e.g. opus-4-3-2. Copy the zip file there, and also unzip it, get out the documentation, and put that in the release directory as well. See an existing release directory for the exact layout. Be sure all the files and directories you create are group-writeable (or else do this as user urbbuild).
Also make a new version of the Eugene sample data zip file and put it in /projects/urbansim5/www.urbansim.org/opus/releases/eugene_data. If the format hasn't changed, just copy the most recent one (or make a symlink). The idea is that for release 4.3.2, there should be a sample data file named eugene_1980_baseyear_cache_version_4_3_2.zip.
Now edit the website page download/index.shtml to include the new release, including the Eugene data. Add what used to be the latest stable release (4.3.1) to the 'Older Stable Releases' section of the website, and edit the 'Latest Stable Release' section to point to the right bits of 4.3.2.
To do: once we start making the Windows installer available for stable releases, make a version of the installer and point the web page at it. Also make a version of the Seattle parcel sample data file.
