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")
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 PRsshould 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?
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.
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.