Page History
Version 1.7.0
...
Tip | ||
---|---|---|
| ||
DSpace 1.7.0 can be downloaded immediately at either of the following locations: |
Warning | ||
---|---|---|
|
...
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
| |
We recommend all DSpace 1.7.0 users upgrade to DSpace 1.7.1, to receive several bug fixes along with a medium-level security fix. For more information see: |
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Info |
---|
Panel |
DISCLAIMER: 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 scheduled 1.7.0 in advance and base based its features on what we are were able to complete within that timeframe. So, Despite the fact that 1.7.0 will be a departure from 1.6.0 in that it may include less new features overall, but will be completed in a much tighter timeframe. |
Organizational
Release Coordination
Proposal for Committer Group 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.
Proposed 1.7 Code Committing Rules:
- 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.
- 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):
had a much tighter timeframe than previous major releases, the developers have managed to include some significant new features, numerous bug fixes and performance improvements. Scheduling releases benefits 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 potentially 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. The DSpace Developers hope to continue this trend of "time based" releases with all future releases. |
New features in DSpace 1.7
Mirage, a clean and professional looking theme for XMLUI. | |
Discover, a faceted browsing and searching interface that gives a deeper and more intuitive look at repository contents. | |
Archival Information Package (AIP) Backup & Restore process. Allows for a backup of DSpace into a generic METS-based structure, that can be used to migrate DSpace content to another system that supports AIP's (DSpace or non-DSpace). This backup and restore functionality also allows one to backup to cloud storage services like DuraCloud, though it could just as easily be used to backup to tape or a hard drive. | |
Curation System , a framework for building and running tasks to help a Curator preserve and improve your repository contents.
| |
Automated Unit Testing of core code -- helps the developers ensure that DSpace is as bug free and stable as possible. Unit Testing coupled with continuous integration on our bamboo server allows us to validate every change to the DSpace code base. Thus letting us know immediately if something changed broke another feature. | |
| Improved Google Scholar metadata exposure. Additional citation_ tags have been exposed to allow the Google Scholar crawler to find better associate repository metadata and PDF content. |
| PowerPoint text extraction, for searching within PowerPoint slides |
| Top 10 Most Visited items list, available for the overall site. |
Performance Improvements
Performance and Scalability improvements. The code has been thoroughly analyzed by a suite of code quality tools to find blatant errors and omissions, more efficient ways of doing things, and implementing general best practices in the code. Additionally, numerous immeasurable performance gains have been made with regard to item ingestion and indexing speed. This was tested by adding a sample-data-generator, in which 400,000 items were added to a repository already containing 100,000 items, where by the total length of time to ingest items reduced to items per second, as opposed to seconds per item. Adding so many items would previously taken weeks or more, but the latest performance feat was done in 10 hours on a laptop. See more at DS-707.
Many thanks go out to Graham Triggs (BioMed Central) for many sleepless weeks to vastly overhaul many weak links.
In addition to that, many other general improvements are:
- Reducing the cost of browse prunes
- SOLR is using autoCommit to reduce resource exhaustion
- SOLR has an optimization function runnable from the command-line for crontasks to essentially "defragment" the solr index.
- Item bitstream sorting/ordering can be specified according to sequence or name
- Moving the documentation into the Confluence wiki so that workload can be divided, and that the documentation is improved.
Bug Fixes
Major Bug Fixes include:
- Batch Metadata Import will now validate metadata fields in CSV's
- Restricted items / metadata is better protected from exposure via web services: OAI
- File handle leak in ItemImporter closed. Fixes issues when max_files_open exceeded on some systems.
- Database connections released when no longer needed in xmlui BitstreamReader. Fixes problem getting connections from the database pool while simultaneously downloading multiple large files.
Changes
For a full list of all changes (new features, improvements, and bug fixes), please visit the Changes in DSpace 1.7.0 section of the new wiki-based DSpace Documentation.
Removed / Deprecated
Most command line scripts that have historically resided in [dspace]/bin/
were deprecated in 1.6.x, and are now removed in 1.7.0. They have been replaced with the configurable command launcher, which eases the cross platform development of scripts. Full details of the discussion are at: http://jira.dspace.org/jira/browse/DS-646.
The old way will no longer work, as the task scripts have been removed:
Code Block |
---|
[dspace]/bin/create-administrator
|
The functionality is all performed by the centralized DSpace launcher, e.g.:
Code Block |
---|
[dspace]/bin/dspace create-administrator
|
Calling a command by its full classname still works by adding dsrun before the classname.
Code Block |
---|
[dspace]/bin/dspace dsrun org.dspace.administer.CreateAdministrator
|
Organizational Details
Release Coordination
- Release Coordinator: Peter Dietz, Ohio State University Libraries
- Release Coordinator: Tim Donohue, DuraSpace
Timeline and Proceeding
Release Timeline:
August 13, 2010 : Milestone 1 - "Feature Decision Day"
October 22, 2010 : Feature Freeze
- 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 8-1219, 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
Panel |
---|
NOTE: The list of new 1.7.0 features has not been finalized. The features listed below may or may not make it into the final 1.7.0 release. Features will only be included if they are ready, stable and documented before the 1.7.0 Feature Freeze date listed above. |
Postponed for a Future Release
The following projects were considered for 1.7, but were not stable enough to be included. They need further review and development from the stakeholders before they are suitable for widespread use, they may be considered for a future release of DSpace. The next release they will be reconsidered for is 1.8
- REST API - Using standard web services to CRUD DSpace Objects. A product of previous GSOC.
- SWORD Client for DSpace – (Robin Taylor, and possibly Richard Jones & Stuart Lewis)
- would allow DSpace to push/submit content to other SWORD enabled repositories
- For closed & open access repositories – add a button to transfer content from a closed to an open repository.
...
- CGIProposal(Richard Rodgers/MIT),
- would allow for type-based submission processes (e.g. Theses/Dissertations could have different submission steps than articles/papers).
- based on the Item type based submission patch
- picked up by Robin Taylor
- CurationTaskProposal (Richard Rodgers/MIT)
- AipBackupRestorePrototype (Tim Donohue/DuraSpace)
- (initially a GSoC project)
- 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.
- Rewrite of Creative Commons licensing (MIT)
- Possibly one or more of the Google Summer of Code 2010 projects (if they are ready/stable enough for release)
Changes
- 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
...
- .