2025-10-01 Breaking Changes Documentation
Date
Oct 1, 2025
Attendees
@Olamide Kolawole
@Tod Olson
@Julian Ladisch
@Christie Thomas
@Maccabee Levine
@Kevin Day
@Jenn Colt
@Matt Weaver
@Ingolf Kuss
@Craig McNally
@Wayne Schneider
@Shelley Doljack
@Mark Veksler
Time | Item | Who | Notes |
|---|---|---|---|
1 min | Scribe |
| @Ingolf Kuss followed by @Julian Ladisch Reminder: Please copy/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. |
|
| The comments on the doc discuss the need for clear communication regarding announcements of changes, particularly breaking changes in backend modules that may affect integrations. There is a suggestion to specify the audience for announcements, ensuring that all affected parties, especially developers, are informed. The importance of a single communication channel for third-party integrations is emphasized, along with the recommendation to merge related module changes in parallel to avoid failures. Additionally, the necessity of considering the number of consumers when deciding on announcements is raised. Suggested Action Items:
Meeting Notes: Olamide: There was a PR about Breaking Changes. Jenn: There is some disagreement of whether a Breaking Change is good. There is a comment: You don’t have to announce a breaking change if it is within your module and only a UI module which is maintained by the same team depends on it → we agree. Kevin: We don’t know, in Open Source projects, if there is somebody outside of the project who uses your APIs.
The Basics
Julian: I disagree. A breaking change is sometimes the better solution. It is often not worth to maintain an old API. Maccabee: … (All:) Communication is important. We can clarify on this.
2. Backwards compatibility. Be perpared to communicate this to other teams. Craig: Others may think that this [breaking change] is the wrong approach. Then, who has the final say ? Maccabee: The module owners will have the final says. Wayne: The TC is to arbitrate disputs. We hope we don’t get to the point where we will have to make a decision over the head of someone else. Craig: These situations are going to happen. We could make a policy that ultimately the module owners will have the final say. Olamide: It should get to the TC if it comes to an impasse. Jenn: The TC is not going to make the decision. The TC will help both sides to work towards a consensus. Wayne: There needs to be a community standard who is outside the module owners. If not the TC, who will it be ? - I like the idea that our role is to build a consensus.
Announcing breaking changes
Kevin: It is not always clear what a dependent module is. Especially, we don’t know who might be using this beyound our core. Maccabee: No particular thought of what other channels or Jiras the change needs to be posted. Craig: At one point, the core team was even creating pull requests towards other modules. Olamide: It will be really hard to make it 100% correct. We should make it going for now.
Maccabee: Not everyone follows the FOLIO developement channel. There should be a low volume to announce breaking changes, which has the word “breaking” in it. Maccabee: The primary discussion might still be on FOLIO developement channel. Olamide : There needs to be some level of notification outside Slack. For example, if ReShare needs to know about the breaking change, there should be some process. Maccabee: The simplest solution to that is an Atlassian Confluence page. It can send a notification when it changes. Olamide: We should announce breaking changes as part of the Release Notes or (on the API page) in Confluence.
Olamide: How can it be done in parallel with the different teams ? It is not practical. Shelley: TC is supposed to build consensus. This should include a timeline. Olamide: I don’t think the TC is able to dictate specific tickets and set a timeline. … The TC could discuss it in a larger group, when it has been brought to the TC. Kevin: The first bullet, Annoucing Breaking Changes, the language “every dependent module” needs to be softened. Not every dependent module is known. Change the language to “best effort”. Olamide: We will post it to the development channel and the sysops channel and the PO channel. | |
NA | Zoom Chat |
| Heute Olamide Kolawole an Alle 17:18 Maccabee Levine an Alle 17:19 Maccabee Levine an Alle 17:26 Jenn Colt an Alle 17:34 Mark Veksler an Alle 17:50 |