Version 1.7.0

We invite developers to help with the next major release of DSpace, version 1.7.0.

Contributors are strongly encouraged to obtain the source code using Subversion (SVN). This is very straightforward, and we've published a guide to doing so here: ContributionGuidelines

Organizational

Release Coordination

• Release Coordinator: Still looking for a volunteer
• Proposal for Committer Team Coordinated Release:
  • Since no one has volunteered as 1.7 Release Coordinator, we could release 1.7.0 based on which features/fixes are ready & documented and have been deemed "acceptable" by the DSpace Committer Group.
  • In this way the DSpace Committers Group would act as the "Release Coordinators"
    • Additional "coordination" would happen amongst various ad-hoc "feature teams" (of interested developers). Those teams would have to work to meet the required schedule in order to get their proposed feature(s) into 1.7.0.
  • However, a lack of a single Release Coordinator may require us all to follow more strict code committing "rules". These rules are here to keep us from stepping on each others' toes, and help us to stay on a tighter release schedule.

1.7.0 Code Committing Rules:

1. No incomplete features in "Trunk", ever. If you are in-progress on a feature, create an SVN sandbox or branch area to work on it, and pull it over to Trunk once it has been completed and is ready for testing & release. (This will hopefully help us to avoid encountering a situation where we need to revert a large, unfinished patch at the last moment.)
   • Modules which do not reside in DSpace "Trunk" should also follow this rule. If there is major rework to be done on a module, create a "branch" to do that work and migrate it back to the Module's Trunk once it is ready for release.
2. All new features must have documentation before committing to Trunk. If a feature has no documentation, it should not be committed to Trunk until there is some minimal documentation (minimal documentation includes documenting all configuration options). This will help us all ensure that Documentation is ready by the time we get to 1.7.0 RC1, and hopefully lessen the time that any one person has to spend cleaning up or rewriting documentation.

Timeline and Proceeding

Proposed Release Timeline (all dates are tentative):

• August 13, 2010 : Milestone 1 - "Feature Decision Day"
  • By this milestone, all major features or major architectural changes for 1.7.0 release should be approved by the DSpace Committers Group and be somewhere in SVN (they need not be fully finished, but should be moving along in their development process).
• October 22, 2010 : Feature Freeze (all features must have initial documentation to be accepted)
  • All 1.7.0 features (major and minor) must be finished, committed to Trunk and have initial documentation. After this date, no new features will be accepted for the 1.7.0 release. Any features which are not finished or ready will need to be scheduled for the next DSpace release.
  • Modules which do not reside in Trunk (e.g. dspace-services) should also undergo a Feature Freeze on this date, so that we can work to stabilize all code used by out-of-the-box DSpace.
• October 29, 2010 : Final Documentation "Due Date"
  • All documentation changes need to be submitted, so that they can be cleaned & packaged up in preparation for RC1. This includes Upgrade Documentation, Release Notes, etc.
    • Obviously, if errors are found in docs, they can be changed during testing process, etc. But, the goal here is to attempt to have as close to a final version of the Documentation as possible, in preparation for the RC1 release.
• November 5, 2010 : Release Candidate 1
• November 8-12, 2010 : 1.7 Testathon Week
• December 3, 2010 : Release Candidate 2 (if necessary), or Final Release
• December 6-15, 2010 : Final Testing / Bug Fixing (if necessary)
• December 17, 2010 : Final Release

Release Process needs to proceed according to the following Maven release process ReleaseProcedure

New Features/Changes

Potential 1.7.0 New Features (very tentative):

• CGIProposal (Richard Rodgers/MIT), based on the Item type based submission patch built by Robin Taylor – would allow for type-based submission processes (e.g. Theses/Dissertations could have different submission steps than articles/papers).
• CurationTaskProposal (Richard Rodgers/MIT) – would allow for a more standard way to integrate curation tools (e.g. virus scanning, format identification, etc) into DSpace
• AipBackupRestorePrototype (Tim Donohue/DuraSpace) – would allow for a more complete backup of DSpace into METS-based Archival Information Packages (AIPs). These AIPs could also be used to migrate DSpace content (Communities/Collections/Items) from one system to another.
• SWORD Client for DSpace? (Robin Taylor) – would allow DSpace to push/submit content to other SWORD enabled repositories
• Rewrite of Creative Commons licensing (MIT) – would improve upon the features of the current CC licensing submission step
• Possibly one or more of the Google Summer of Code 2010 projects (if they are ready/stable enough for release)

Changes

See the DSpace 1.7.0 JIRA Page for a list of all currently proposed changes.