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, July 31, 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

10.0 Release Schedule & 10.0 Release

  • No updates, first deadlines don't come until later this year
  • Merger discussions are still in progress – no new updates or developments that can inform the 10.0 release

Other topics

  • There is a discussion ticket in GitHub around the topic of aggressive bots attacking DSpace sites: https://github.com/DSpace/dspace-angular/issues/4565
    • Please contribute to this discussion so that we can understand better how different DSpace sites are dealing with this problem
  • Allan Orth from Google has mentioned that our current rate limiter setting is out of date
    • Anyone is welcome to update this setting by upgrading the rate limiter; if you're interested, please reach out; Tim might create a ticket for this
  • There is an endpoint with bad performance: https://github.com/DSpace/RestContract/blob/main/submissiondefinitions.md#single-submission-definition
    • When the list of collections is very large, this endpoint slows things down significantly
    • Paulo has created a PR that removes the endpoint to test whether this improves performance
      • Improvements seem significant; load times went down from ca. 1 minute to ca. 200ms 
    • If anyone wants to help look at this problem or if anyone knows why we embedded this in the submission definition in the first place, please reach out
    • Giuseppe thinks this is connected to switching from one collection to another in the submission form
      • Need to double check if this is the place where it is used
      • Instead of removing the endpoint, could we stop the embed by default and make it optional?
        • First need to see how it behaves with hundreds of collections; better to have the form load quickly and load the collections in a different call?
    • Another option is to just follow the link when the site is loaded – why do we need to have all the definition objects load in the workflow process? This is currently unclear
    • Kim will help take a look at this; Paulo, Giuseppe also added as assignees on the ticket

Upcoming Topics

  • Migration to NX
    • First PR that is coming soon is just restructuring things, second PR will be NX migration
      • Once first PR is ready to go, assign to Tim, he can review that quickly; if anyone interested in testing, please let Tim or Giuseppe know; we aim at discussing this next week
      • 2nd PR: 4Science will open two PRs for NX; one standalone application and a different PR with monolithic approach (allows for multiple applications in same project)
        • We can then decide which approaches works better for us

10.0 Board Reviews

  • #11041
    • This is an update to ROR, which is time sensitive as ROR may stop working soon 
    • If anyone is interested in helping, please assist with this
    • Assigned to Vincenzo
  • #1117
    • This makes sure that all policies we inherit are custom
    • Need help with this one, please consider whether you can assist
  • #9814
    • Tries to limit "add community collection menu" in sidebar
    • There has been some testing, but we need additional feedback
  • #10103
    • Tested by community member, but has not been reviewed at all
    • Briefly reviewed this together, seems risky to merge as-is; Tim and Kim added to take a closer look
  • #10459
    • Briefly reviewed this together; code seems solid
    • Need to find a tester who can try this out, Giuseppe volunteered
  • #10490
    • Code seems reasonable, seems something we can merge relatively quickly
    • Tim will further review and add comments on to PR

Action items