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.

Developers Meeting on Thurs, October 9, 2025

Time/Location

 from 14:00-15:00 UTC

Location: https://lyrasis.zoom.us/my/dspace?pwd=RTk4QUhISnhPRi9YenVrTFJKbDllQT09 (Meeting ID: 502 527 3040).  Passcode: dspace

10.0 Release Schedule (TENTATIVE - Not Finalized)

  • New Feature Development Deadlines
    • Feature PR Creation Deadline: Friday, February 20, 2026
    • Feature PR Review/Test Deadline: Friday, March 13
    • Feature PR Merge Deadline: Friday, March 27
  • 10.0 Release Candidate:  Friday, April 3
  • 10.0 Testathon: April 6-17 (two weeks)
  • 10.0 Translation updates: April 6-17 (during Testathon)
  • Bug Fix Deadlines
    • Bug Fix PR Creation Deadline: Friday, May 1
    • Bug Fix PR Merge Deadline: Friday, May 15
  • Documentation & Release Week: May 18-22 
  • 10.0 Release Announced: Tuesday, May 26, 2026

Agenda

Attendees

Current Work

Project Boards

To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested  (This is also available in the GitHub header under "Pull Requests → Review Requests")

Goals for 10.0

To be decided by DSpace Steering Group with feedback from Leadership Group

Priorities listed at DSpace Release 10.0 Status

Goals for 9.2 / 8.3 / 7.6.5

Deadline is TBD for 9.2, 8.3 and7.6.5.  Bug fix releases do not have fixed/scheduled deadlines. Instead, the developer team will determine when to create a release based on the significance of the issues to solve. (e.g. If major issues are fixed, then a bug fix release will occur more rapidly.  If minor issues are found, then a bug fix release may be delayed until sufficient fixes have been made to warrant a release)

  • Bug/security fixes only.  These minor releases will not include any new features.
    • New "themeable components" (for dspace-angular) are allowed in bug fix releases, provided that they don't significantly modify component behavior or similar.
    • Accessibility fixes are also allowed in bug fix releases, provided they don't significantly modify component behavior or similar.
  • Bug fix PRs should be created against "main" branch where possible. The "main" branch has the most strict code style rules. (i.e. PRs created against dspace-7_x  are becoming more difficult to port forward.)
  • Per our support policy, bug fixes are only guaranteed to be ported back to 9.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 8. x and 7.6.x.

Try "Pull Request Trading" for a quicker review

Do you have a PR stuck in "under review" that you really want to see move forward?  Or maybe it's someone else's PR but you want to get it more attention?

See Trading reviews on Pull Requests for how to get immediate attention to that PR!

Notes

  • DSpace & DSpace-CRIS potential merger discussions
    • No major updates.  Technology group meets later today.
    • Both groups are working on documenting final recommendations to Steering.  Final decisions on merger will be made by Steering and Leadership Groups.  Timeline for decision is not yet set.
  • Revisiting Audit Trail discussions. What is "good enough" for DSpace 10?
    • Key concern is using Solr as the "primary storage" for Audit Trail.  We want to avoid existing frustrations encountered with Usage Statistics (which also use Sol for primary storage).
    • Lots of good discussion about best approach to move forward.
    • Tim summarized the discussion on the issue ticket in this comment: https://github.com/DSpace/DSpace/issues/8824#issuecomment-3386250414
    • Please add additional feedback to that ticket, if you have any.
  • Clarifications added to DSpace Software Support Policy recently by Committers
    • On dspace-devel, there was a good question about how we manage Angular upgrades to older supported DSpace releases: https://groups.google.com/g/dspace-devel/c/rT1WA_JjkX4
    • This brought up a discussion among Committers about updating our DSpace Software Support Policy to clarify how we manage Angular upgrades (and upgrades of dependencies in general)
    • New bullet point added under "Support for Security Updates → Version(s) Supported" which notes the "Limits to support for dependency updates". See DSpace Software Support Policy
    • Basic idea is that we can only guarantee security updates to DSpace's own code.  When it comes to updating dependencies, it may not be possible to always update dependencies when the update is not "backwards compatible".
    • This comes up most frequently with Angular because Angular releases are only supported for 18 months, and unfortunately are not often "backwards compatible".
    • This means older DSpace supported releases (7.x and 8.x currently) are running unsupported versions of Angular.  They cannot be upgraded to latest Angular because doing so isn't backwards compatible, and would be the equivalent of upgrading to DSpace 9.x.
    • Basic message: We recommend running the latest major release for the most secure DSpace experience. Older releases may be on unsupported versions of Angular.
    • If you have questions, bring them to the dspace-devel email thread (see above), or to the #dev channel on Slack, or to a future meeting.