You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Michael Marth <mm...@adobe.com.INVALID> on 2017/07/14 15:29:17 UTC
Releases of rOpenWhisk (was: Updating Package and Language versions
for a kind)
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" <jt...@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 <ro...@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
Re: Releases of rOpenWhisk (was: Updating Package and Language
versions for a kind)
Posted by Sergio Fernández <wi...@apache.org>.
+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" <mm...@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" <jt...@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 <ro...@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
>
Re: Releases of rOpenWhisk (was: Updating Package and Language
versions for a kind)
Posted by Raymond Camden <ra...@gmail.com>.
And it would be great if this was accompanied with a good blog post
detailing the high points. To be clear, not a list of changes, PRs,
whatever. That's important - but most developers want a summarized
list of the important updates.
On Mon, Jul 17, 2017 at 10:50 AM, James Thomas <jt...@gmail.com> wrote:
> +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 <mm...@adobe.com.invalid> wrote:
>
--
===========================================================================
Raymond Camden, Developer Advocate at IBM
Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden
Re: Releases of rOpenWhisk (was: Updating Package and Language
versions for a kind)
Posted by James Thomas <jt...@gmail.com>.
+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 <mm...@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" <jt...@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 <ro...@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
Re: Releases of rOpenWhisk (was: Updating Package and Language
versions for a kind)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jul 14, 2017 at 5:29 PM, Michael Marth <mm...@adobe.com.invalid> wrote:
...
> “If OpenWhisk did start to produce "releases""
...
Apache podlings have to produce releases in order to graduate. The
technical quality of those releases is not really important from the
Incubator's point of view, what counts is that the release process and
contents are according to Apache rules and principles.
So yes, doing releases would be great.
-Bertrand