Version 9.0

Table of Contents:

Under Discussion for 9.0

The following is a (incomplete) list of features / priorities that are currently under discussion for the 9.0 release.  Features/ideas listed on this list are NOT guaranteed for 9.0 until approved/prioritized by the DSpace Steering Group.

• Improving performance / scalability in general
  • High CPU usage for server-side rendering, https://github.com/DSpace/dspace-angular/issues/3110
  • Serve configuration more efficiently: https://github.com/DSpace/DSpace/issues/9056
• Configurable Entities (by default)
  • What do we need to achieve to enable Entities by default?
  • How can entities be made more usable?
  • Improving scalability/performance/functionality of Relationships
  • Nested/hierarchical metadata  (e.g. dates on a Person's affiliation with an OrgUnit)
• Angular : library-based architecture proposal - As of 8.0, we've already migrated to "standalone components". We can now consider whether to potentially migrate to using Nx.
• Shall we automatically change metadata in flyway migrations? 
  • Entities
    • If entities are enabled by default how could a migration look like? Shall we offer a script to add a field dspace.entity.type="Publication" to all items without an entity type? 
  •  DOIs
    • Changing the field a DOI is using (dc.identifier.uri vs. dc.identifier.doi)
    • Changing the resolver (https://doi.org vs. http://dx.doi.org)
• Bitstream persistence

  • Current behavior

    • Current URLs on item pages are similar to /bitstreams/2d35dc29-47a7-4a62-a87b-8b1fb10594ee/download

      • This will first handle authentication, and hereafter redirect the user to the REST url

    • The REST url is similar to /server/api/core/bitstreams/2d35dc29-47a7-4a62-a87b-8b1fb10594ee/content

      • This can’t handle authentication, and is used by Google (the URL which is indexed) and most often by users if they want to share the link to the file

    • If you need to replace the bitstream, a new bitstream has to be created with a new UUID, and the old bitstream has to be deleted. They are in no way linked to each other

    • When using versioning, and not changing the bitstream, the new item will contain a bitstream with a different UUID, which references the same file. They are not related to each other in the bitstream’s metadata. Cut there are two URLs which both point to the same file. This may lead to perceived duplication of the files as well

  • Desired behavior

    • The urls should both be independent from the UUID if we want to allow url persistence

    • The newly uploaded bitstream should be linkable to a bitstream it’s replacing. And the bitstream of the new version of the item (during item versioning) should be linked to the bitstream from the older item

    • In DSpace 6, this was handled using the sequence ID. Download urls were based on the combination of the item’s handle and the bitstream’s sequence ID. This concept could be used to support replacing a file while keeping the URL consistent

    • In DSpace 7, there’s also versioning support for items. Depending on the configuration, the handle without suffix would always lead to the latest version

    • Based on these concepts, it should be realistic to build a URL for both Angular and REST which can at all points in time link to the latest version of the file

• Replace Submission Form library (as the one we use is unmaintained): https://github.com/DSpace/dspace-angular/issues/2216
• Permissions
  • Possibility of granting granular permission to individuals and groups to edit / see only some metadata

Priorities for 9.0

To be decided.  9.0 is still in very early planning phase. Priorities have not yet been established.

Tickets & Pull Requests to review for possible inclusion

All potential tickets & pull requests may be found on our 9.0 Project Board. 

• 9.0 Project Board: https://github.com/orgs/DSpace/projects/31

If there is a feature you wish to work on which is not on that 9.0 Project Board, please create a GitHub issue ticket to describe it (or find one if it exists) and contact Tim Donohue (via email or Slack) about possible inclusion in 9.0.

Keep in mind, even if a ticket/PR exists on the 9.0 Project Board, that does not guarantee it will be completed in time for 9.0.  All development & testing/reviewing is volunteer based.  You can help ensure a PR's inclusion by volunteering to help test or review the code! Any work that cannot be achieved in time for 9.0 will be rescheduled for a future release.

Organizational Details

Release Coordination

The 9.0 Release will be coordinated by Tim Donohue and the DSpace Committers.  

Updates and discussions will take place in weekly Developer Meetings.

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.

Release Process needs to proceed according to the following Maven release process: Release Procedure