At the May 5th Release Management Stakeholders meeting, discussion of the Sunflower release date (proposed at May 19) led to questions regarding the status of the Early Adopter Eureka testers and if they feel confident to run FOLIO on Eureka.
Kristin summarizes RMS meeting: Positive news from Oleksii that Sunflower testing almost done, Sunflower seems ready to be released on May 19. Oleksii wanted a Go/No-go. Stephen Pampell brought in that councils endorsed release timeline, with requirements, see links above. In particular, the Eureka early adopters (GBV, ID, TAMU) should be positive about implementing Eureka. Oleksii probably was not informed on requirements, consequently surprised and concerned. Group agreed to hear status from early adopters and discuss how to proceed.
Sascha reports from GBV on early adopters:
Platform complete could be deployed, but not production ready. Missing till now:
SSL encryption not fully depployed; technical difficulties with different versions of SSL
Application descriptors cannot be changed atm, only those provided by EBSCO work
Migration plans need to be worked out
Time estimation difficult
Mark: GBV will probably not go into production with Sunflower in the next months
Mike reports from Indexdata:
little behind GBV, next week they will have base platform
running a platform is fine, but still need to find out how to load data etc. and upgrade from Ramsons/Okapi to Sunflower/Eureka
migration path is not clear
automated deployment and mgmt processes must be adjusted
timeframe: probably in Oct 2025 first lib with S/Eureka
most concern: 0 chance that all customers will upgrade from Q till November 10, 205. That means that some customers will then running on unsupported Okapi.
Jeremy reports from TAMU:
recent progress, got running but only with compromises that are not bareable for production:
Eureka seems the right way to go but still much to do for production
timeline: move to Eureka probably not before early summer 2026
Stephen P adds:
need of sufficient confidence in such critical infrastructure, concern that TAMU falls behind on “Okapi island”, becoming ever more difficult to catch up
Eureka still very young, puts risk on self hosters. Need more time
Jeremy: Early adopters are first to test Eureka outside AWS environment, example: credentials mgmt uses different tools
Kristin: How far are EA on steps regarding setting up Eureka vs. migration to Eureka?
Stephen: all EA still on step 1
Sascha: self hosters have specific, different adoptions/setups that each may need quite different timeframes
Martina: GBV invests all available resources, EBSCO efforts are greatly appreciated; GBV would like to make sure that the support for Okapi does not end with Trillium
Jeremy: agrees to Martina; delaying S or T is just a means of the community to extend Okapi support. Maybe better extend support for Okapi than delay S/T. TAMU has primary goal to have Ramsons/Okapi CSP-supported till mid-2026. An option may be to establish Community Driven development and let this dev group take care of extended Okapi support. TAMU would be willing to explore this option.
Mark: agrees to Jeremy, need to decouple release and support plans. When T is released in Nov 2025, only security issues may still come up in Ramsons. CSPs typically get smaller each time. This reduces effort a lot, most probably they can be backported from S/T.
Jeremy: CDD group has thought on what would need to happen for CDD to come into being and considered question on how much would that support cost. Put a price tag on it would be a good next step.
Kristin: What EBSCO customer has already succesfully migrated from Okapi to Eureka?
Harry: LC initial testing on Q/Okapi then migrated that on R/Eureka (multiple steps?; full deployment but not production). Close to a “normal” production migration.
Mark: LC is now on Eureka with R. Galileo is being upgrated from Ransoms/Okapi to Sunflower/Eureka. Two more big libraries are testing Eureka migration. EBSCO will share migration tools with early adopters.
Jenn on chat: Cornell has test instance on Eureka
Jeremy: there should be some Wolfcon sessions on migration, esp. permissions
Mark: there have been sessions submitted. Cooperation with early adopters really great exercise/experience
Alexis: Community supporting Ramsons/Okapi is a great idea. What would be the next steps? cost questions, timeline?
Jeremy: discuss proposal on tri-council meeting next week; Tri-C working group may be needed, work out decision that the councils commit to; PC already has submitted a wolfcon session for community driven development where this could be communicated
Jenn is there a TC rep on the CDD group?
Jeremy: currently only PC, but would be good to have TC as well
Kristin: delaying S/T releases would be very disruptive, many/some big libraries rely on the timeline. This CDD support fits needs of all sides.
Mark: willing to contribute technical experience to CDD group
Stephen P: would appreciate help from EBSCO on estimating effort/costs/resources
Mike: Closing the door now for postponing release? Still a lt of uncertainty/risk if community can bring up costs for support. Difficult decision but would go this road.
Alexis: Before closing the door, let’s explored this in more detail, even if this would mean a little delay for S
Stephen: Cannot allow to happen that all dev is switching to Eureka but only EBSCO really running the platform. Need to have other hosters running Eureka. CDD idea is a feasability study in that is the community able to do that
Mark: S release date is decided by RMS group, this group makes final decision on release date.
Jeremy: To his understanding, RMS group operates under the endorsement of the PC as stated by the governance document, and RMS makes decisions on behalf of PC
Mark: Disagrees, not expressed in charter, should to re-look at charters.
Alexis: What our next step as Councils?
Kristin: Can Jeremy share feasability study for Tri-C meeting?
Alexis: discussions will continue on slack and tri-council meeting