These are a few notes on the release process

Release steps

I usually release by doing the following:

• Use the test server (griddev01) to setup a fac simile of the production server. I take the copy of the gums.config from the prod server, modify it to make sure that the test server is not going to corrupt the data, and put it on the test server.
• Polishing phase, which means run it as if it were the prod server, simulate gatekeeper coming in (with the command line client), run functionalities old and new, and fix whatever things are not right (including typos, logs that are not clear, ...)
• Once you are confident that everything is good enough (which unfortunately is subjective), create the first packaged release. Change the release number in the main project.xml file (./siteAAA/GUMS/project.xml), which will change for all GUMS components, create the packages, install on the test server to see that they work correctly
• Install the package on the production server and leave it there for some time (within which no changes in CVS are allowed). If you see a problem, fix in CVS, rebuild the packages and install. No need to change the version number, essentially it's like you are creating a new beta every time. The build number, which is the time in which you build, is information enough for you to know what version you are installing. If you are not making the betas public, there is no need to go to the extra effort of renaming.
• While you wait, it's a good time to actually review the manual, and fix all the things that are now outdated
• When you have enough confidence (two weeks of smooth running are enough), tag CVS (the usual format is GUMS_1_1_0 for GUMS 1.1.0, be sure that _everything_ was actually in CVS before tagging, including the modified project.xml), build the final packages, modify the download page information to include the new release
• Change back the version in project.xml to SNAPSHOT
• Make the announcement on the appropriate lists

That's it!