Versions Compared

Old Version 9

changes.mady.by.user Robin Taylor

Saved on

compared with

New Version 10

changes.mady.by.user Mark H. Wood

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added tasks for the beginning of a release cycle

Release Coordinating

Excerpt

This page gives some notes on how to go about coordinating a DSpace release.

The Release Coordinator

The release coordinator is elected from any volunteers for the position. Usually there is only one volunteer! Each Release Coordnator will have their own 'style', so it is likely that each release will be coordinated in a slightly different way. Use your own preferred style, following the outline below:

...

  • The release coordinator is responsible for building the release package and uploading it to SourceForge. See Release Procedure for information on how to do this. At the same time as releasing a file the coordinator 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.

Things to Do at the Start of a Release Cycle

  • Review prerequisite software (DBMS, Java, etc.) version requirements with the developer community, and adjust them as required.  Keep the documentation of this up-to-date.
  • Review dependency (e.g. log4j) version requirements and adjust as required.  Tools such as mvn dependency:analyze can help.  Also remember non-Java things such as Javascript libraries.  This could be a big job, so ask for volunteers to help.

In general, try to establish a stable up-to-date foundation for development and integration early on.

Tips

  • It is never too early to start thinking about the release.
  • It is never too early to start talking about the release. People are busy and need reminding.
  • Try and create a provisional list of major features as soon as possible, even though it will undoubtedly change throughout the year.
  • Engage with the developers and gently push for development and commit timescales. Just talking may help speed the process.
  • A commit date for a major feature of one week before the feature freeze is too late, it will inevitably result in a postponement of the feature freeze date. All code needs review and probably rework, developers need to recognise that and plan accordingly.
  • Don't be afraid to badger people. It goes with the role and people expect it.
  • Don't be afraid to ask for help.