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, September 10, 2026

Time/Location

 from 14:00-15:00 UTC

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

11.0 Release Schedule (TBD)

  • New Feature Development Deadlines
    • Feature PR Creation Deadline: Friday, February __ 2027
    • Feature PR Review/Test Deadline: Friday, March __
    • Feature PR Merge Deadline: Friday, March __
  • 11.0 Release Candidate:  Friday, April __
  • 11.0 Testathon: April __-__ (three weeks)
  • 11.0 Translation updates: April __-__ (during Testathon)
  • Bug Fix Deadlines
    • Bug Fix PR Creation Deadline: Friday, May __
    • Bug Fix PR Merge Deadline: Friday, May __
  • Documentation & Release Week: May __-__ 
  • 11.0 Release Announced: May/June, 2027

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 11.0

Finish the merger of DSpace and DSpace-CRIS. Other priorities be decided by DSpace Steering Group with feedback from Leadership Group. 

Priorities listed at DSpace Release 11.0 Status. 

Goals for 10.1 / 9.4 / 8.5 

Deadline is TBD for 10.1, 9.4, 8.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-8_x  are becoming more difficult to port forward.)
  • Per our support policy, bug fixes are only guaranteed to be ported back to 10.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 9.x and 8. 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

General

  • Maintenance releases for DSpace 10.x, 9.x, and 8.x are coming up soon.
    • Current plan is to cut the releases on Monday September 14

DSpace & DSpace-CRIS Merger

Discussion: "trustedBot" list of IPs for fine-tuned SSR

  • Consider creating a "trustedBot" list of IPs for fine-tuned SSR (to filter out aggressive bots). Open ticket: https://github.com/DSpace/dspace-angular/issues/6212
  • This brainstorm came out of discussion with the Google Scholar team. The goal is to see if we can find ways to ensure SSR is kept turned on, in this case by perhaps only turning it on for "trusted bots". (SSR is often turned off to protect from aggressive bots, but this will also block Google Scholar.)

  • Pascal: Not in favor, if DSpace community would have to decide the list of trusted IPs to be included as a default, which could be controversial

    • Noted we should focus on efforts toward improving performance and caching for the frontend, and why it takes so much resources to run DSpace in production

    • Tim: Agree, though need to keep in mind caching solutions that are simple enough to work well for smaller sites too

    • Drew: Noted the political aspect may be avoided if the feature is off by default and does not include specific IPs as default. "It seems that this is not incompatible with caching or other solutions and may be faster to incorporate"

  • Paolo: expressed that using Anubis has worked well so far

    • Google Scholar team says that their crawlers also should work fine with Anubis

    • Tim: Suggested sharing out some basic Anubis configuration examples

  • Probably we'll need to come at the problem from several angles in parallel (document tools such as Anubis, caching improvements, trustedBot list idea, etc.)

  • Wiki page will be created based on what has been discussed in #4565 and some options of what has worked so far (such as Anubis)

  • Other followups:

    • Please add any thoughts and feedback to #6212

    • If you have caching solutions that have worked better and are willing to share, please do so

Additional discussion topics

  • Solr PR, ISO 639-1 language codes unsearchable due to stopwords: https://github.com/DSpace/DSpace/pull/12960 
    • Discussion re: minor or major release, when schema config changes (config update + reindex required, but not full core recreation)
    • Breaking changes like this are sometimes included in minor releases
    • Comment if you have an opinion on whether there's enough impact/priority to backport this
  • Hidden Metadata / Metadata Security and DSpace Discovery 'search by field': Discussion of options to harden this better
    • There have been a few problems reported about this; likely an open ticket 
  • Recent issues marked "Needs Discussion" (Take a look and add comments)


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