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" <[email protected]> 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 <[email protected]> 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
