2025-12-03 Using Spring Boot milestone and release candidate releases in development

1 min

Scribe

@Wayne Schneider followed by @Florian Gleixner

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.

Using pre-releases in development

Julian

Due to the timing of Spring Boot releases there's a proposal to use Spring release candidate and milestone releases at least during development, in order to be able to use a version of Sprint Boot for the maximum amount of time. Spring Boot 4.0 end of OSS support is 2026-12-31 but if we are willing to move to 4.1 during development, the end of life will be 2027-06-30. (edited) 

1:39

Draft OST reflecting this: https://folio-org.atlassian.net/wiki/spaces/TC/pages/966852629/Umbrellaleaf#Third-Party-Libraries-/-Frameworks

Draft migration guide: https://folio-org.atlassian.net/wiki/spaces/FOLIJET/pages/1163264001

Discussion:

@Mark Veksler: clarifying that backporting to Sunflower is out of scope (confirmed). Are we talking about Trillium or just Umbrellaleaf? (Ideally both to maximize support coverage)

@Shelley Doljack: difference between an release candidate and a milestone release?

@Julian Ladisch: milestone release is an in-progress preview of features, RC is feature-complete with only bugfixes expected before release.

@Mark Veksler: The risk would be that the FOLIO flower release would ship before the release of Spring, and then we would be in the position of making a release based on unreleased code. A decision point would need to be added to the release cycle to be certain we are working with released code.

@Julian Ladisch: Spring release dates are fixed and known long beforehand.

@Craig McNally: We did suggest something like this previously. @Julian Ladisch remembers that it was part of the OST but there was pushback from release management so it was removed.

@Mark Veksler: The release management planning group would need to select a release date for FOLIO that lines up to maximize the Spring support period.

@Jenn Colt: We would need to change our processes to be more proactive to set Spring versions before the FOLIO release date is set. Would require greater collaboration between RMSG and TC.

@Mark Veksler: Add additional milestone to release planning calendar to ensure alignment.

@Jenn Colt: Rather than recommending development with a particular RC, we collaborate with RMSG to identify a target Spring version and add a checkpoint to the calendar. Does our draft OST come before the first “straw man” release schedule or after? (Consensus that it should be after). Have we reached a conclusion?

@Julian Ladisch: Yes, but key stakeholders are absent.

@Jenn Colt: Bring this to the RMSG next meeting? (if there’s time)

Action: Julian will bring this to RMSG in Slack.

NA

Zoom Chat

2025-12-03 10:07:56 From Maccabee Levine To Everyone:
Not a dumb question!

2025-12-03 10:12:35 From Craig McNally To Everyone:
I think this is the closest we have to a documented policy about releasing modules with unreleased dependencies: https://dev.folio.org/guidelines/release-procedures/#prepare-the-news-document

2025-12-03 10:13:05 From Craig McNally To Everyone:
Do NOT create releases with SNAPSHOT dependencies!
It doesn't explicitly mention anything about 3rd party dependencies

2025-12-03 10:28:05 From Mark Veksler To Everyone:
:-)

2025-12-03 10:28:53 From Mark Veksler To Everyone:
When planning a Flower release, make sure to review and reach agreement on all third-party upgrade dependencies, and account for them in the overall release timeline and scope.

2025-12-03 10:29:01 From Maccabee Levine To Everyone:
That does seem like the best way to do it (RMSG vote) as they are a group, rather than just input from "key people"