+1 Start rolling out releases shows the maturity of the project. Besides that's a very important indicator for formal Incubator assessments.
Definitely the first release is the hardest. So don't hesitate to get all the possible help from us the mentors. On Jul 14, 2017 17: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 >
