Editor: RichardJones <r.d.jones@...>
Date: 2005/03/21 06:50:48
= Release Coordinating =
This page gives some notes on how to go about coordinating a DSpace release (based exclusively on RichardJones experience so far, so add more help if you can).
* Determine whether a major or minor release is required. Minor releases include bug fixes and minor, non-db-schema-altering changes; mostly minor releases can be installed by replacing the DSpace code. Major releases include major functional enhancements, configuration changes and db schema alterations.
* Determine a feature freeze date. In a normal release cycle, there will hopefully be a constant influx of patches waiting to be rolled into the relevant release. The feature freeze date, therefore, need not be a long way in advance. It's useful if the date is a Friday, as this allows trailing time-zones to catch up before work in earnest can start on code integration on the Monday.
* Announce to dspace-devel, dspace-tech and dspace-general lists the date of the feature freeze for the coming release, requesting patches and bug fixes
* The job of the release coordinator is not to test all the patches and fix all the bugs, but to help others in doing so. Advise the list of any important events in development and liaise with patch authors to ensure smooth development
* Remind people of the feature freeze enough time in advance to ensure that they can get their patches in on time
'' Everything from here is speculative, as I've not done it yet - Richard J ''
* Aid other committers in assigning or testing patches.
* Set a beta 1 release date and a tentative final release date. Once the first beta is out it should be possible to gauge how much longer it might take before the final release. Once a final release date is set, do the best you can to stick to it to avoid a hold up on subsequent releases. Remember, OSS is often released with known bugs, these can always be fixed in a minor revision later.
* The release coordinator is responsible for building the release package and uploading it to SourceForge. See ReleaseProcedure for information on how to do this. At the same time as releasing a file the RC should also email dspace-devel, dspace-tech and dspace-general to announce the release and add a news item to the SF project page. See other news items for examples of the format of such announcements.