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 versioned? 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 fixes. 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? Regards, Rob... [1]: https://github.com/apache/incubator-openwhisk/pull/2415#issuecomment-314716101 <https://github.com/apache/incubator-openwhisk/pull/2415#issuecomment-314716101>
