DSpace 6.x Release Notes have been incorporated into the DSpace 6.x documentation wiki. The content of that page, and this one, is similar, but it's not a perfect duplicate. This page is for coordinating and planning DSpace Release 6.0, and for communicating this status information to the community. This Release Status page is a historical document, with much of the same material.

Table of Contents:

New Features in DSpace 6.0

DSpace 6.0 ships with a number of new features. Certain features are automatically enabled by default while others require deliberate activation. The following non-exhaustive list contains the major new features in 6.0

Major Java API refactor, supporting UUIDs and Hibernate. The DSpace Java API has been refactored significantly to make it more modular, and make it easier to achieve future RoadMap modularity goals. For more detailed information, see DSpace Service based api or DS-2701. This feature was contributed by Kevin Van de Velde of @mire, with support/help from the DSpace Committers.

Hibernate allows us more stability in our database layer (decreases the likelihood of database specific bugs), and potentially allows us to support additional database platforms in the future

UUIDs provide all objects with stable, globally unique identifiers (instead of existing incremental, non-unique database identifiers). This simplifies the management of identifiers in our object model. See also DS-1782.

The Java API itself is now split into three "layers" which are all now initialized via Spring

Most sites will not notice this major API refactor, as the upgrade is seamless. However, if you've performed major (Java-level) customizations, you may need to refactor your own customizations to use this newly refactored API. Some examples are on the DSpace Service based api page.

Provides easier management of local configurations via a new local.cfg file. Any configurations (from *.cfg files) can be overridden in DSpace by simply copying them into your local.cfg and changing the value. See Configuration Reference

Many configurations now automatically reload as soon as you save your local.cfg file. This means you don't need to restart Tomcat every time you need to change a configuration.

Please note: Unfortunately, at this time, some configurations do still get cached in the XMLUI or JSPUI (or similar). So, while many will reload, not all of them yet support this feature.

Enhanced file (bitstream) storage plugins, including support for Amazon S3 file storage. This feature was contributed by Peter Dietz of Longsight.

New framework for metadata import from external sources (including an out-of-the-box plugin supporting PubMed, and hopefully more coming soon). This concept was previously only supported in JSPUI. Screencast example: http://screencast.com/t/QBImSGbAUZ. These features were contributed by @mire. The PubMed metadata import plugin was also contributed by the Netherlands Cancer Institute.

REST API now provides a version via /status endpoint (inherits the version of DSpace API). See DS-2619. This feature was contributed by Ivan Masár.

Search/Discovery enhancements

All searches now default to boolean AND. See DS-2809. This enhancement was contributed by Andrea Schweer.

New "Has File" facet, which allows you to easily filter by items that have one or more files. See DS-2648. This enhancement was contributed by Christian Scheible.

Full text indexing of Excel spreadsheets, so that they are now searchable. See DS-2629. This enhancement was contributed by Ed Goulet.

Right-to-left text in PDFs is now indexed for searching. See DS-1187. This enhancement was contributed by Saiful Amin

Other enhancements:

PDFBox was upgraded to version 2.0 (DS-3035). A new PDFBox Thumbnail generator was also added and enabled by default (DS-3052). These features were contributed by Ivan Masár.

OAI-PMH was upgraded for compliance with the OpenAIRE 3.0 guidelines for literature repositories. This enhancement was contributed by Pedro Príncipe.

Features Removed or Replaced in 6.0

The build.properties configuration file has been replaced by an enhanced local.cfg configuration file. The new local.cfg allows you to easily override any configuration (from dspace.cfg or modules/*.cfg files) by simply copying it into your local.cfg and specifying a new value. It also provides enhanced configuration options as detailed in the Configuration Reference documentation. The old build.properties file is no longer used nor supported.

WARNING: As part of adding this new configuration scheme, many of the configuration settings in DSpace (primarily those in modules/*.cfg files) had to be renamed or prepended with the name of the module. This means that 5.x (or below) configurations are no longer guaranteed to be compatible with 6.x. If possible, we recommend starting with fresh configs (see below), and moving all your locally customized settings into the new local.cfg file.

The PDF Citation Cover Page configuration file has been renamed (from disseminate-citation.cfg to citation-page.cfg). See this feature's documentation for more details.

The legacy search engine (based on Apache Lucene) and legacy Browse system (based on database tables) have been removed from DSpace 6.0 or above. Instead, DSpace now only uses Discovery (based on Apache Solr) for all Search/Browse capabilities. See DS-2160. The legacy browse system was removed by Kevin Van de Velde. The legacy search system was removed by Tim Donohue.

The DSpace Lightweight Networking Interface (LNI), supporting WebDAV / SOAP / RPC API, has been removed from DSpace 6.0 or above. We recommend using REST or SWORD (v1 or v2) as a replacement. However, if you still require it, the old (unmaintained) LNI codebase is still available at https://github.com/DSpace/dspace-lni. This change was contributed by Robin Taylor of University of Edinburgh.

Support for SRB (Storage Resource Broker) file storage has been removed from DSpace 6.0 or above. As it was unmaintained (and seemingly unused) for many years, this feature was removed along with its configurations. As a replacement, a new file storage plugin system was added, featuring a traditional local file storage option (default) and an Amazon S3 file storage option (see Storage Layer documentation, especially Configuring the Bitstream Store). For more information on the removal of SRB support, also see DS-3055. This change was contributed by Peter Dietz of Longsight.

The user groups Administrator and Anonymous cannot be renamed or deleted. If you had renamed them, they will be renamed back to the stock names during the upgrade. DSpace is now dependent on these specific names due to internal changes. This change was contributed by Mark Wood of IUPUI.

XPDF PDF Thumbnail generation has been removed. Please use the ImageMagick or PDFBox thumbnail generators instead. See DS-2159. This change was contributed by Mark Wood of IUPUI.

The default strategy to create new handles for versioned Items has changed. If you have Item Level Versioning enabled and you have versioned Items in your DSpace installation, you may want to change the configuration to continue using the mechanism to create handles as it was in DSpace 4 and 5. You can find more informations here: Item Level Versioning#IdentifierServiceOverride.

Elasticsearch Usage Statistics feature is deprecated in the 6.0 release. While they still function, and you can continue to use them, in a future DSpace release they will be removed. If you are looking for a usage statistics option, we recommend instead using the default SOLR Statistics engine and/or DSpace's integration with Google Analytics. See DS-2897 for more information.

Release Coordination

Release Team Members

Timeline and Processing

Your contributions are welcome now! Code and documentation need not be finished, so long as it is working and we can all see what it is for. Time is set aside for fixing, polishing, and integration. We have some general Code Contribution Guidelines available, but you are also welcome to ask questions on the dspace-devel mailing list.

Release Timeline

Please note that the dates below are estimates of when particular activities may occur. As there are many factors involved in a major release, these are subject to change.

Date

Milestone

What it means

November 12

Deadline for feature pull requests

If you wish to contribute features to DSpace 6.0, you must submit a pull request by this date.

November - January

Review, merger and conflict resolution between pull requests

The entire hour's meeting will be used to discuss proposed features submitted by the deadline.

March, 2016

Feature freeze

DSpace 6.0 is considered feature-complete on this date. Only bugfixes will be pulled between this date and final release.

April 22

Release Candidate 1 tagged

A DSpace 6.0 Release Candidate will be available for wider testing.

April 25 through May 6

Testathon

Intensive public testing of the 6.0 Release Candidate is invited. The Release Team will focus on getting problems resolved.

June 10

Release Candidate 2 tagged

An updated DSpace 6.0 Release Candidate will be available for wider testing.

Príncipe

7 Comments

It was mentioned in the DCAT meeting the other day that testers would be needed for the Testathon, scheduled for December. I thought it might help recruit / get feedback from more testers if you had a testing schedule for them to work through, as we use here at EDINA for our own DSpace instance, see attached DataShare Testing Results Blank v2.xlsx - makes it quick and easy to go through the different processes and make sure you've tested them in different browsers , and as different kinds of users, since you just have to go through it and fill in each box one-by-one.

Thanks for sharing your spreadsheet, Pauline Ward. This does look like it'd make for a useful tool during Testathon.

It makes me wonder if we could simply migrate that to a public Google Doc, perhaps enhance it with even more DSpace features, and then ask our Testers to mark off each box as they test it. Doing so would definitely allow us to more easily ensure that each feature has been verified, and avoid extensive, duplicative testing.

Thanks, this is great. I second Tim's suggestion that we should have a testing script in this form. But for the Testathon it should be a lot more detailed, at the level of individual steps (and each UI), so that even a person completely new to DSpace can do the testing. That will allow us to paralelize the testing across multiple people and still be sure the same actions were performed. Granted, the steps to do something sometimes change, but that doesn't happen a lot with core features and the script can be updated at any time.

Yep - if the developers want to add in more testing steps, I expect DCAT could then also take a look at the document, just to provide a wee bit of feedback if necessary, Maureen WalshIgnace Deroost maybe could we put this on tthe agenda for one of the telecons before the Testathon please?

I'd recommend considering whether DCAT would actually do a better job with creating this script. While the developers could surely provide feedback, and fill in gaps, we'll be busy enough trying to stabilize and wrap up the next release. I worry if we leave this script to the developers as well, we might not get as far along prior to testathon. So, if this is something DCAT would have time to help us enhance over the coming months, I think it'd be a huge benefit to the entire community. Pinging Bram Luyten (Atmire) and Maureen Walsh to see if there's a role here for DCAT.

I agree it would be a great idea to discuss such testing schedule. Not only could we decrease the testing workload for the developers like Tim already mentioned, we could also increase interaction between DCAT and the developers. With the upcoming new UI in mind I believe this would definitely be beneficial.