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!

Reply via email to