openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <mma...@adobe.com.INVALID>
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…

Michael





On 13/07/17 11:02, "James Thomas" <jthomas.uk@gmail.com> wrote:

>Good ideas Rob. I had a similar issue when looking at the Swift runtime
>recently.
>https://lists.apache.org/thread.html/fa01baca7d97d08c855abfc69fc17a23e038115fcfc4f2a31d650fa1@%3Cdev.openwhisk.apache.org%3E
>
>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 <rob@akrabat.com> 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]: https://github.com/apache/incubator-openwhisk/pull/2415#
>> issuecomment-314716101 <https://github.com/apache/
>> incubator-openwhisk/pull/2415#issuecomment-314716101>
>
>
>
>
>-- 
>Regards,
>James Thomas
Mime
View raw message