Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

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

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

  • Release Coordinator: Peter Dietz, Ohio State University Libraries

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

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.

Potential 1.7.0 New Features (very tentative – reviewed on July 5 before OR10):

  • 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 - ready to go) – better metadata for Google Scholar (citation tags in header).
  • CGIProposal (Richard Rodgers/MIT – Interface & XML serialization implementation should be ready), based on the Item type based submission patch 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 (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
  • 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.

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.