Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Reminder: Please take attendance. Please paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
5-15 min
Liaison Updates
@Maccabee Levine
@Christie Thomas
@Craig McNally
CC: @Maccabee Levine
PC: @Christie Thomas
PC Decision log (for all decisions outside of the endorsement process)
Discussion of the Community Directed Development DIP process was postponed.
@Maccabee Levine Had question about module that has some confusion.
Module that had significant functionality changes where the PC endorsed a project after TC evaluated and there was some controversy/confusion. Most of this confusion is resolved, but not everything is fully aligned yet.
There should be a list of open issues in a more public space. There is a lot of change currently at the process level.
@Maccabee Levine pointed out that there are other processes or groups that have no place and can be included in this public space.
RMS Group: @Jenn Colt
OST wanted to upgrade to Kafka 4.2, but that is not yet supported by Spring-Boot. The Kafka upgrade to 4.2 might be done via a CSP once Spring-Boot has a release with support. Kafka 4.2 brings in breaking changes. We need to specify versions of software that is compatible with Kafka 4.2. There needs to be extensive testing. Sunflower is currently running Kafka 3.x. Trillium uses Kafka 4.1.
Ebsco has already tested Kafka 4.1 and it works well.
Kafka 4.2 can be run in 3.x compatibility mode and this is being tested.
@Wayne Schneider points out that a major upgrade can be disruptive.
The Kafka 4.2 will be deployed into snapshot for testing.
For Spring-based modules, we can manually bump that up (for testing and preparation) but we will not actually switch to it in Spring-based modules until Spring officially releases with support for Kafka 4.2. When this happens, there will be a CSP release made.
There will likely be a Spring minor version change by then (like Spring-Boot 4.1).
ZooKeeper was fully removed in Kafka 4.2.
We need to communicate to the community that when a CSP is released there will be a structural upgrade due to this.
Amazon (AWS) takes 6 to 8 months to do their extensive testing. Probably by the end of August or October Amazon will have support for Kafka 4.2.
Security Team: @Julian Ladisch
The number of published issues in 3rd party dependencies is more than 6 times as high as in 2025 when comparing the months January until May:
Waiting on KitFox to set up and environment to test it out (by the end of this week).
@Charlotte Whitt is wondering what developers and POs are expected to do as the situation is currently a bit messy. Please follow up with update in Implementor SIG channel. Adding new item information seems problematic.
They did the POC, but right now they are not able to incorporate all of they data that they want. They are going to deep dive to see what is possible. See RFC draft.
Where to store information regarding side-cars, kong configuration, specific to modules is still ongoing and an open discussion.
Its unclear at the moment on how to update the schema for the module descriptor.
@Wayne Schneider is wondering about the two wiki pages. One under the release procedures where we have been putting comments and now there is this RFC. Is the ready for review document to be considered closed? The answer is Yes. The RFC (draft) is now the source to use.
@Tod Olson askes for the old page to have a statement or link clarifying that it is closed and to instead use the RFC.
0 min
Existing Module Evaluation
All
Module Evaluation Queue:
@Florian Gleixner and @Shelley Doljack can wrap up the current in progress issues.
The yarnpkg/yarn repository describes itself as the source for Yarn 1.x, says newer releases are tracked in yarnpkg/berry, and says the 1.x repository is kept mostly for historical purposes and occasional hotfixes. Its contributing note says the 1.x codebase is old and only accepts security fixes; new features and bugfixes go to the newer repository. Latest Yarn Classic release shown: v1.22.22 on 2024-03-09.
What is blocking us from moving away from Yarn 1?
Summary response from @Zak Burke Mostly inertia and prioritization — Yarn v1 is old but not broken, and upgrading it is invisible maintenance work that keeps losing out to feature work. A Yarn v4 migration was actually completed and approved (PR #31, STRIPES-907) but shelved due to poor Windows support; the likely future direction is pnpm rather than newer Yarn, driven partly by npm supply-chain security concerns. The real question is what work we'd deprioritize to make room for it.https://github.com/folio-org/.github/pull/31
Stripes: Change the OST text from Likely Stripes ^11.0; possibly only Stripes ^10.2 to Stripes ^11.0 or later 11.x
@Wayne Schneider Thinks that backwards compatibility is not bad. If there is no issue with backward compatibility, then is there a reason to force a newer version. @Olamide Kolawole points out that its already Stripes 11, so we might as well set that.
React: Public npm reports current stable react and react-dom as 19.2.6. FOLIO registry metadata for @folio/stripes-core@11.1.2, however, lists peer dependencies react: ^18.2.0 and react-dom: ^18.2.0.
Change the OST text to React ^18.2 for now
Cypress: Current OST choice: Cypress 12.0 or greater, plus Pending verification.
What verification do we need? I heard we are stuck on a specific version of Cypress since the next version is a paid product. Is that accurate?
Kafka: Trillium version of 4.2 lead to some confusion. Release management inferred that Kafka clients and broker should be updated to 4.2. 4.2 is not currently available as a managed service in AWS. We should pivot to recommending 4.x instead.
For Trillium we should recommend 4.2, and for AWS recommend 4.1 until 4.2 gets available. Apache Kafka has a short support period of only 12 months, therefore we cannot recommend older versions than 4.2.
@Julian Ladisch We should set minimum to 4.1. @Olamide Kolawole agreed.
According to OST process, https://folio-org.atlassian.net/wiki/x/M4OQKw should be ACTIVE because we are past Sunflower’s feature development freeze date & Umbrellaleaf should be likely to be ACTIVE because Umbrellaleaf’s scope composition deadline has passed(DRAFT → ACCEPTED) then we are past Trillium’s feature development freeze date (ACCEPTED → ACTIVE). This means we should lock-in third party edits soon.
Next Wednesday meeting will be to review the OST pages.