Version 4.0

DSpace 4.0 is still in the planning stages and will be released sometime in late (likely Nov/Dec) 2013

Table of Contents:

Wish List for DSpace 4.0 (tentative)

The list of features below is entirely speculative. Features are not deemed finalized until the code is in-hand and accepted.

If you are a developer and you'd like to contribute to DSpace 4.0, you can do so by doing the following:

Submit a JIRA ticket describing your contribution, and mark it as being for "4.0" (this will cause it to auto-appear in the listing below)
As early as possible, share your code via a GitHub Pull Request (or link to it if it's available publicly elsewhere). Add a link to it in your JIRA ticket. See Development with Git for more info.
If it's a larger contribution, please provide some documentation (you are welcome to create a new page in this DSpace Wiki), so that we can understand how to use it and configure it.

The earlier you make your contribution known, the more likely it is that it will be accepted into 4.0. The later you share your code / ideas, the more likely it is that we'll need to reschedule it for a later release. Usually we need to have the contribution in-hand (or at least be well aware of what it involves) before Summer to ensure it won't conflict with other contributions and can get a thorough review.

Please feel free to list features / contributions you plan to develop for 4.0. You can also add a JIRA ticket and mark it for "4.0" which will put it on the automated list below (see "Possible JIRA tickets to resolve")

Conceptual Ideas / Proposals

Metadata for All Objects: In the Developers Meeting on Jan 30, 2013, those in attendance discussed a need to release an updated version of this "Metadata for All" pull request (#12). However, we may need the following:
- An updated version of the pull request based on current "master"
- We like the suggestion to rename "schemas" to "namespaces"
- We'd like it to use "metadatavalue" (and similar) tables rather than creating a new set of Metadata tables specific to other objects. We understand this may be more disruptive, but it seems odd to have different metadata namespaces
- If possible we'd want this change to be "backwards compatible" with existing UIs. The goal would be to perform this change in stages – first update the APIs to allow for metadata on all objects, then update each UI one-by-one. Hopefully we can get all of the UIs done before 4.0
- We also obviously could use some basic documentation / overview of the thinking behind it, so that we can vote this through sooner rather than later.
REST API: We would like to have a stable, tested, read/write, documented, standards based REST API available. Already a working group has been formed to review the existing API's, and to evaluate the existing API's, and to research development of a new API. The API will either be included with the out-of-the-box DSpace, or it will be released a module to be enabled separately. The API working group will host a discussion panel at OR13 during the DSUG track. An API available will enable further re-use of repository data. Existing use-cases of the project range from building JS widgets to spit out a researcher's publications in repository to building a frontend web application.
DOI Support (Pascal-Nicolas Becker & Mark Wood)
- Bram Luyten (Atmire): I think this work looks very promising and would be great to get finalized for 4.0. On the maillinglist, I also saw Pascal Nicholas's wish to get this into 4.0
SWORDv2 module update (see Git Repo: https://github.com/nye-duo/DSpace/tree/swordv2contrib), which provides the following improvements:
- some general bug fixes including: bitstream url construction, config options, context management and connection pool, ORIGINAL bundle problem ( Unable to locate Jira server for this macro. It may be due to Application Link configuration. )
- proper METSDSpaceSIP support in both deposit and update
- proper authentication for accessing actionable bitstreams (i.e. those that can be replaced via sword), tightened security options around mediated actions, and add extra security to the access of descriptive documents (deposit receipts, statements)
- more configuration options: bundles to expose in Statements, DepositMO extensions (for individual files), and many more
- some general refactoring
- addition of 404 responses where necessary
- better support for add/replace of metadata, and how metadata updates are handled on archived items
- update to latest version of Java Server library
- new bitstream formats in the bitstream registry

Possible JIRA tickets to resolve (automated list)

This is the list of JIRA tickets ("New Features" and Improvements) currently scheduled for 4.0. There is no guarantee they will all be completed in time for 4.0 release, and tickets may be dropped/added to the list at any time. But, if you'd like to volunteer to help with one, please let us know by attaching a comment to the ticket in question.

key	summary	assignee	reporter
Data cannot be retrieved due to an unexpected error. View these issues in Jira

Changes

The following changes have already been made to the codebase and will be released in 4.0. Please note that the below listing is dynamically generated, so it will be changing as we continue to add new features, improvements and bug fixes to the 4.0 release.

New Features in 4.0

key	summary	assignee	reporter
Data cannot be retrieved due to an unexpected error. View these issues in Jira

General Improvements in 4.0

key	summary	assignee	reporter
Data cannot be retrieved due to an unexpected error. View these issues in Jira

Bug Fixes in 4.0

key	summary	assignee	reporter
Data cannot be retrieved due to an unexpected error. View these issues in Jira

Organizational Details

Release Coordination

Instead of a single "Release Coordinator", the DSpace 4.0 release will be managed by a "Release Team".

Release Team Leader

To be decided - Please feel free to volunteer if you are interested!

Release Team Members