openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <>
Subject Releases of rOpenWhisk (was: Updating Package and Language versions for a kind)
Date Fri, 14 Jul 2017 15:29:17 GMT
James, all,

“If OpenWhisk did start to produce "releases""

I had it in my backlog to ask this - are we ready to do releases? I think we are, but wondered
if something is holding us back that I am not aware of…


On 13/07/17 11:02, "James Thomas" <> wrote:

>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
View raw message