Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • For a list of all features/improvement/bugs currently scheduled for 1.8.0, see the 1.8.0 Version in our Issue Tracker.
    • NOTE: This listing is not finalized, and is likely to change. Not all features/improvements/bugs currently scheduled for 1.8.0 are guaranteed to be in that release.

Developers: Add what you are working on to this list. Please try and link off to additional documentation (on Wiki) or related JIRA issues.

More Curation Tools/Plugins (MIT & Others). Obviously, some could potentially even be release asynchronously, and also formally "bundled" with 1.8.0

  • Configurable Reviewer Workflow (@mire) a project that enhances Reviewer Workflow configurability that is orthogonal to Curation Tooling.
  • Core Service and Service Manager Refactorings
  • REST API formal release? It missed 1.7.0, but there seemed to be interest there. Volunteer(s) to stabilize/improve for 1.8.0? (Still working on it, also volunteers/testers are welcome :) Bojan Suzic
  • DSpace "Easy" Installer (Tim Donohue)? See DS-802 and InstallerPrototype for more details
    • Perhaps, alongside this, an easier way to "install" plugins/addons (like Curation Tool plugins)??
  • 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.
  • Context Guided Ingest (Richard Rodgers/MIT) – 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?
    • 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 (initially a GSoC project)
  • Usability improvements / new Theme work (Peter Dietz)
  • Discovery Enhancements
    • Discovery back end rewrite to support other back end implementations beside solr for discovery (Created by Kevin Van de Velde see DSCR-22)
    • Improved discovery configuration which utilizes spring & a config file that is located in the modules dir (Created by Kevin Van de Velde see DS-971)
    • New Discovery user interface ? (Provided by Kevin Van de Velde or @mire ?)
  • Rewrite of Creative Commons licensing (MIT)??
    • 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.

...

  • Very Tentative Release Timeline (This should not be considered final)
    • August 19, 2011 : Feature Freeze Date
    • September 2, 2011 : Final Documentation "Due Date"?
    • September 9, 2011 : Release Candidate 1 release
    • September 12-23, 2011 : Testathon
    • October 7, 2011 : Release Candidate 2 release
    • October 10-19, 2011 : Final Testing / Bug Fixing
    • October 21, 2011 : 1.8.0 Final Release
  • A few definitions:
      "Beta" Releases - These are a newly proposed idea for 1.8.0. Essentially a "Beta" release would be an very early release of the software, even before all features are finalized. They give developers an opportunity for early feedback from the community or other developers around a new features. They should not be considered stable (though hopefully they are relatively stable). Rather they are previews of upcoming features. Only features that are completed will be released into the Beta Release (i.e. the Beta Release waits for nothing – we release a new Beta even if there's not many new features completed). After and between Beta releases, features may change, up until the "Feature Freeze"
    • "Feature Freeze" - After this date, the feature listing cannot change. All new features must be completed by this date. After this date, the system is being stabilized in preparation for the first "Release Candidate"
    • "Release Candidate" releases - These are initial releases after all features have been finalized. Features may not change, but bug fixes can be made. They are meant for very broad testing (e.g. Testathon), in order to find & fix any last bugs before the Final Release.

...