The most important thing is that I would keep the current runtimes for the upcoming release 0.9.0
Michele Sciabarra | CPO m: +44 747 984 8388 e: [email protected] l: https://linkedin.com/in/msciab Nuvolaris Inc | 1209 Orange Street, 19801Wilmington DE - US www.nuvolaris.io linkedin.com/in/msciab On Thu, 13 Aug 2026 at 21:45, Bruno Salzano <[email protected]> wrote: > Hello, > I'd like to bring to your attention two related topics, to gather ideas, > suggestions, and recommendations on which strategy to adopt. > Apache OpenServerless provides OpenWhisk runtimes that support some of the > most popular languages, including Python, Node.js, PHP, Go, and Java. > > *1) Language versions reaching EOS status* > Over time, some supported language versions reach EOS (End of Service) > status. > We currently have the following status: > > - Python → EOS: v3.10 — v3.14 to be added > - Node.js → EOS: v18, v20, v21 — v26 to be added > - PHP → EOS: v8.0, v8.1 (v8.2 coming soon) > - Go → EOS: v1.20, v1.21, v1.22, and v1.24 — current versions v1.25 and > v1.26 to be added > - Java (IBM Semeru OpenJDK) → EOS: v24 — LTS version v25 to be added > > EOS status means that support, bug fixes, security updates, and bug fixes > are discontinued for a given version. > A runtime based on an EOS version will naturally continue to function, but > it would be appropriate to evaluate whether and how to inform the user of > the runtime's status and define a possible migration path to a supported > version. > > *2) Version updates to address CVEs* > The second issue concerns the need to keep runtimes up to date even when > the main language version remains unchanged, but updates are released that > address security vulnerabilities (CVEs). > For example, the move from PHP 8.5.6 to PHP 8.5.7 introduces fixes for some > CVEs. This means that, even while maintaining the same language version, > the associated runtime should be updated to incorporate these fixes. > > Strategy > > The two issues are closely related, and I believe it is appropriate to > define a common strategy for managing the runtime lifecycle. > In particular, it would be helpful to share your opinions on: > > 1. how to manage runtimes based on EOS versions; > 2. whether and how to communicate to the user that a runtime is using a > version that is no longer supported; > 3. how often to update runtimes to incorporate security updates and CVE > fixes; > 4. how to manage the transition to new language versions, preventing the > number of runtimes to maintain from growing indefinitely. > > What do you think should be done? What strategy do you suggest for these > two issues? > > Sincerely, > Bruno > -- > The life is short.. live at your best! >
