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, May 15, 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


9.0 Release Schedule

  • New Feature Development Deadlines
    • (tick) Feature PR Creation Deadline: Friday, February 21, 2025
    • (tick) Feature PR Review/Test Deadline: Friday, March 14
    • (tick) Feature PR Merge Deadline: Friday, March 28
  • (tick) 9.0 Release Candidate:  Friday, April 4
  • (tick) 9.0 Testathon: April 7-18 (two weeks)
  • (tick) 9.0 Translation updates: April 7-18 (during Testathon)
  • Bug Fix Deadlines
    • (tick) Bug Fix PR Creation Deadline: Friday, May 2
    • Bug Fix PR Merge Deadline: Friday, May 16
  • Documentation & Release Week: May 19-23 
  • 9.0 Release Announced: Monday, May 26, 2025

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 9.0

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

Priorities listed at DSpace Release 9.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

9.0 Release Schedule

  • Tomorrow, Friday, May 16 starts code freeze. Anything that doesn't get merged by tomorrow won't get into 9.0 (except for severe, absolutely necessary clean-up work)
  • Next week is final testing time, updating documentation, etc. 
  • Release will come out near end of next week; announcement will occur the following week

Updates and Reminders

  • Open Repositories is coming up; if you're able to attend, there is a DSpace Developer Meet-Up and Q+A
    • Add any topics to this page if there is anything you'd like to discuss or if you would like to lead a discussion, showcase your repository, feature, customization, etc. 
    • Feel free to reach out to Tim if you have any questions
    • All DSpace-related presentations, talks, workshop at OR25 are listed on DSpace at OR2025
  • Merger: No new updates; discussions are ongoing in the Strategy and Technology Group

9.0 Release

  • High Priority PRs still being merged before the deadline: https://github.com/orgs/DSpace/projects/31/views/1?filterQuery=label%3A%22high+priority%22
  • #3889:
    • Moving along, can hopefully be merged after this dev meeting
    • Allows users to manage capturing correlation ID in cookie pop up
    • Does not need to be backported to 8.x or 7.x as this is specific to the orejime library (previous versions use claro cookie)
  • Other PRs are waiting on #3889
  • #3613:
    • Allows users to manage how long pop-ups stay around
    • Configure how long messages occur in live region (e.g. for screen readers)
    • Impacts cookie consent pop-up
    • Once 3889 is merged, we can get this reviewed and merged before the deadline
    • Backported to 8.x and 7.x 
    • Anyone who wants to do final testing of this functionality, Tim would appreciate additional help
  • Other PRs (not high priority): https://github.com/orgs/DSpace/projects/31/views/1
  • We will try to get the "Reviewer Approved" PRs still merged
    • #3390:
      • Plan to merge this right at the end
      • This PR helps with code cleanup and restructuring and sets us up for future development (10.0, potential merger, etc.)
      • There are new linting rules that will be applied 
        • Also discussed #4329 in connection with linting rules
          • Art will try to review this one right after the dev meeting
          • As long as this one works fine, we can get this in before the cut-off date; is currently passing automated tests, needs manual testing
    • #10611:
      • Ready to be merged; minor change to ensure that iiif manifests have correct mime type
    • #10730:
      • Fixing a bug, REST API returning improper status code (currently 200, should be 404)
      • Has automated tests; actual fix is only 15 lines of code
      • Will test this more on UI side, has a slight chance of having side effects in UI 
      • Raised the question whether 200 ok is actually the correct error code; an empty list with a 200 ok seems to be a valid result
        • This also needs to be consistent with other parameters, such as filters, DSO types
      • We will delay the PR and have more discussion around this ticket; suggestion: we could return a 204 code
  • If anyone is still doing translations for 9.0, Tim will do his best to get these in by today or tomorrow
  • Tim will do a quick scan for performance, accessibility and translations PRs to see if there are any "quick wins" that we can include in 9.0
  • Next week's meeting: we will finalize the release, getting things ready for the release
    • Looking towards bug fix release for 8 and 7
    • What comes next? 10.0 discussion, dependent on merger, but we can start brainstorming things we'd like to recommend back to Steering

Action items











  

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