openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Thomas <>
Subject Re: Updating Package and Language versions for a kind
Date Thu, 13 Jul 2017 09:02:00 GMT
Good ideas Rob. I had a similar issue when looking at the Swift runtime

Would it be possible to have a scheduled upgrade process for installed
modules? Once every four, six or eight weeks? If OpenWhisk did start to
produce "releases", it could tie in with that.

I'd guess that most people using the built-in packages are more kicking the
tires than building production apps. Once you start being a production app,
you'll want to explicitly bundle and control your app dependencies. I'd +1
on being more aggressive with upgrading module versions.

I'd like to have a Github issue to follow for this, I find it easier than
the mailing list.

On 13 July 2017 at 09:33, Rob Allen <> wrote:

> 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]:
> issuecomment-314716101 <
> incubator-openwhisk/pull/2415#issuecomment-314716101>

James Thomas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message