Version 1.7.0

We invite developers to help with the next major release of DSpace, version 1.7.0, which is planned for release in December 2010.

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

DSpace 1.7.0 is a scheduled, "time-based" release. In order to decrease delays in releasing new features and increase transparency, the DSpace Developers have decided to schedule 1.7.0 in advance and base its features on what we are able to complete within that timeframe. So, 1.7.0 will be a departure from 1.6.0 in that it may include fewer new features overall, but will be completed in a much tighter timeframe.

Scheduling releases will benefit us all as it should decrease the delays in releasing new features, and increase the transparency of the development process. The DSpace Developers feel that these benefits will far outweigh the cost of having fewer major features in a given DSpace release. We hope the DSpace Community will also realize the immediate benefits, which should allow them to receive new features more quickly, rather than potentially waiting years for the next major release of the software.

Organizational

Release Coordination

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.)
  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):

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

New Features

NOTE: The source code is still volatile as fixes and improvements are still flowing in.

New Features in XMLUI

New Features in JSPUI

Improvements

Graham Triggs has launched a Code Quality crusade and has dug into deep and dark corners of the DSpace source code armed with nothing more than a torch, machete, and a fancy plugin called QAplug to systematically drive out evil spirits haunting the DSpace code. See: https://jira.duraspace.org/browse/DS-707

In addition to that, the rest of the general improvements are:

Bug Fixes

Changes

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

Removed / Deprecated

Most command line scripts that have historically resided in \[dspace\]/bin/ were deprecated in 1.6, and are now removed in 1.7. They have been replaced with the configurable command launcher, which eases the cross platform development of scripts. Discussion at: \[http://jira.dspace.org/jira/browse/DS-646\|http://jira.dspace.org/jira/browse/DS-646\].

Example usage of the launcher:

One can no longer run:

[dspace]/bin/create-administrator

The method of calling the DSpace launcher is now:

[dspace]/bin/dspace create-administrator

Unsure / Postponed for Next Release

Note: Developers, you need to contact the release coordinator and get approval to commit a feature that did not make it in by the feature freeze date. The sooner you tackle this the better the chance that your code will not cause a problem with the release schedule.

There are a few projects that were strongly desired to make it into DSpace 1.7, however, work will need to be done to make them into the release, or they are going to be postponed for the next release of DSpace, likely 1.8.

Rewrite of Creative Commons licensing (MIT - ready to go) – would improve upon the features of the current CC licensing submission step
* Currently only against XMLUI from MIT
* Legacy problem – do we update old license to new or not? Currently MIT runs 'split version' with old licenses looking like old, and new look like new.

Google Scholar work (MIT - on hold) – better metadata for Google Scholar (citation tags in header).

Google Scholar has clarified their requirements for the use of this metadata, such that more development is needed for this feature to be contributed.  (Specifically, they require a direct link to a PDF bitstream if the metadata is to be included at all, which is difficult because of the generic content model DSpace has, which could include many variations of bitstreams, with no one way to specify the canonical, representative PDF for the Item (if there even is a PDF for the item).  Discussions are going on with Google Scholar to clarify exactly what defines an acceptable set of citation metadata tags, and what defines a condition where none of it should be included, currently understood as a lack of direct PDF URL.  

New localization? We have made localization for Serbian language, need several days to finish quality evaluation.. according to documentation in Release Procedure it can be accepted before final release? Bojan Suzic 10/27 -

\*\[CGIProposal\|CGIProposal\]* (Richard Rodgers/MIT -- Interface & XML serialization implementation should be ready), based on the **\[*{*}Item type based submission patch{*}*\|http://jira.dspace.org/jira/browse/DS-464\]** picked up by Robin Taylor (initially a GSoC project) -- would allow for type-based submission processes (e.g. Theses/Dissertations could have different submission steps than articles/papers).*
*Context Guided Ingest -- define an interface, where any submission code can write "attributes" and can retrieve those again later on. Can add any new attributes/values that you want for your submission code. Could be serialized to XML (using input-forms.xml) OR have an implementation of that service that stores in DB (recommended). JPA2?*
*seems similar to SimpleStorage Service (user centered storage of state info) -- Mark Diggory.*

*\*\[*{*}CurationTaskProposal{*}*\|CurationTaskProposal\]* (Richard Rodgers/MIT -- some will be ready) -- would allow for a more standard way to integrate curation tools (e.g. virus scanning, format identification, etc) into DSpace Lightweight framework to attach curation tasks -- 3-4 tasks for 1.7. These could be kicked off by commandline (in batch) or Admin UI (potentially) 1. Automated replication
2. Streamlined Checksum Checker
3. Virus Checker - ClamAV (Tcp socket communication)
4. ??? Better content format identification (may not be ready for 1.7)
Could relate to Scheduler service (Spring based) in Modules area. Allows you to register & schedule events. -- Mark Diggory

Possibly one or more of the \[Google Summer of Code\|Google Summer of Code\] 2010 projects (if they are ready/stable enough for release)
 \- REST API?  -\- Based on previous discussion on developers list / irc channel it will be most probably released asynchronously. It is in the process but RC 1 deadline is too short for all parts to be implemented. Bojan Suzic Oct. 10/27 \-\-

SWORD Client for DSpace? (Robin Taylor – may be ready, Richard Jones & Stuart Lewis are interested in helping) – would allow DSpace to push/submit content to other SWORD enabled repositories

DCDate improvements: has DCDate been rewritten / replaced ?