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 3, 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 8.2 / 7.6.4

Deadline is TBD for both 8.2 and 7.6.4.  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 8.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 7.6.x.
    • Keep in mind, if a specific bug fix is important to you in 7.6.x, then it is best to create two PRs (one for main and one for "dspace-7_x").  If you are able to provide a backport version of the PR, then we will merge it alongside the "main" branch version.
    • NOTE: In many scenarios, a backport to "dspace-8_x" should be possible to automate using the "port to [branch]" labels & the "Port merged Pull Request" GitHub Action

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

  • There is a tentative schedule (top of this page), which still needs to be finalized and approved by Steering, DCAT

DSpace & DSpace-CRIS potential merger

  • No updates or reports at the moment
  • An update about the merger will soon be sent out to the community

Maintenance Releases

  • Won't be able to get them out today – there is a security issue that has been reported in DSpace 7.x, 8.x and 9
    • We have been digging into that to understand it better and want to apply fixes before releasing maintenance versions
  • We are aiming now at July 8 or 9 to get the release out the door
    • Because of the extended deadline, there is a little bit more time to get fixes into the maintenance releases

DSpace 10.0

  • Lot of bug tickets on 10.0 board if you are looking for anything to do
  • Also lots of PRs to review

Upcoming Refactoring & Modularization Work

  • Migration to NX and modularization: No updates; further work will occur in the next three weeks
  • Restore dynamic component decorators: Art gave update on progress of work
    • Q: Where is the map generated? A: in a folder with one file for each decorator
  • Giuseppe assigned to decorators PR, Tim will take a look at this as well
    • Giuseppe will review Alex's PR and provide feedback
    • He will let Tim know if he wants to give an update in an upcoming dev meeting
  • Want to try to get these two merged relatively quickly, need to think about which one to merge first
    • May make sense to merge the decorators PR first, as it's smaller.  But, Giuseppe will take a look at it to see if it can easily be worked into the NX PR. 
  • Discussing how the NX PR is structured
    • Art notes we may want to consider using the default "libs" directory that NX uses.  Currently, the PR renames this folder to "modules".  Recommends we name "modules" back to "libs" 
    • The current PR is just the first phase.  This is where we is split parts of DSpace into libraries (in "modules" folder).  Currently just two libraries "core" and "shared/utils".  Everything else is still in the "src/app" directory.
    • Future Goal is to get the "src/app" folder as lean/empty as possible.  It should be possible for institutions to use the "src/app" folder for only the code they want to override .  This would let the "src/app" directory work similar to the Maven overlays that were used in DSpace 6 (and below) – "src/app" would let you overlay/override any defaults in the "modules" folder.
    • The main question is how to get to that goal.  This PR is just the first phase.
      • 2nd phase could be to move everything out of the "src/app" folder immediately into a single massive module.  Then 3rd phase would be to break that massive module apart into many different small modules
      • Or, 2nd phase could be to move things out of "src/app" folder little-by-little, into separate modules.  The goal would still be to get everything out of "src/app", but we'd just do it module by module.
  • For anyone interested to check out how NX works, create a new NX app and play around with it
  • There is a wiki page that discusses the NX proposal (as to why to even look at NX)

Other topics

  • Question for Angular experts: can we explain more about the transferState configuration in PR 3953? 
    • State refers to NGRX state – before this PR, after server-side rendering, we would transfer state from server to client (through piece of JSON) to avoid having the client need to make the same requests already made by the server.
    • Q: Is there a situation where we want to set transferState to false? A: 4Science sets it to false in their production instances.
      • It might be useful to document better when to set this to false (and give a reason why)
    • Currently this configurate seems to exist just because there are scenarios where you might want to set transferState to false...but most may want to keep it as true.
  • If anyone interested in discussing test configuration, there is an issue open to clean all of this up 


Action items




  

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