+1 on moving towards an official regular release process. This would also improve my life as a maintainer of open-source tools that integrate with OpenWhisk. The project is moving at an increasing velocity, which is a good sign 😎, but I'm finding it extremely difficult to keep up with changes as a "downstream" consumer.
It would be ideal to have official releases that the providers could then advertise as being available on their platforms. On 14 July 2017 at 16:29, Michael Marth <[email protected]> wrote: > 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/fa01baca7d97d08c855abfc69fc17a > 23e038115fcfc4f2a31d650fa1@%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 > -- Regards, James Thomas
