openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <>
Subject Updating Package and Language versions for a kind
Date Thu, 13 Jul 2017 08:33:22 GMT
Hi all,

On the PHP PR, @rr [commented] [1]:

> The built in packages are convenient - less zip files for the initial ramp up. But it
creates a maintenance issue: when do you pick up updates to the packages (minor/patch level
only?) and not break existing actions using the "kind". That is: is the kind itself semantically

This applies to all kinds and so probably should be discussed project level and ideally we
should document how this is handled.

There are two things here:

1. The language runtimes release patch updates for minor versions. e.g. PHP `7.1.7` will become
`7.1.8` next month with a small number of bug fixes including crashers and possibly security

2. Each kind bindles a number of packages via the language's standard package management system:
Swift Package Manager for Swift, NPM for NodeJs, etc. The projects that produce these packages
update them with new versions minor and patch versions.

The tension is obviously between keeping updated for fixes vs the risk of breaks due to a
project's inability to keep BC between patch versions. e.g. the NodeJS kind comes with the
`async v2.1.4` package. However `v2.1.5` of that package fixes a stack overflow issue. Should
our actions have that fix? Closer to home, the NodeJS kind ships with `OpenWhisk v3.3.2`,
but the latest is `v3.6.0` which is needed for non-experimental API Gateway support… 

Some questions:

1. Should we update the language runtime for a kind for a patch level change (e.g. update
the current NodeJS:6 kind from `6.9.1` to the latest `6.9.5`?
2. Should we ever update the language runtime for a kind for a minor level change (e.g. update
the current NodeJS:6 kind from `6.9.1` to the latest `6.11.1`?
3. Should we ever update the packages in a kind to the latest patch level or minor level?
4. What's our policy when a security issue is published for a language or a package that we
ship in a non-deprecated kind?

Whatever the answers are, I think we should document them clearly somewhere.

Also, I've started this conversation as a mailing list topic as it's a "policy" thing. Given
my previous comments on mailing lists, should I also create a GitHub issue prefixed with "Discussion"
to provide more visibility in order to garner wider community input?



[1]: <>
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message