openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Thomas <jthomas...@gmail.com>
Subject Re: Releases of rOpenWhisk (was: Updating Package and Language versions for a kind)
Date Mon, 17 Jul 2017 15:50:36 GMT
+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 <mmarth@adobe.com.invalid> 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" <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/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 <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
>



-- 
Regards,
James Thomas

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message