You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by David P Grove <gr...@us.ibm.com> on 2019/01/07 21:55:12 UTC
time for next OpenWhisk release wave?
I would like to see us push out a consolidated next release in the near
future (by end of January?). I'd also like to see us attempt to establish
a regular cadence of such consolidated releases (perhaps quarterly?).
We would start this release from the leaves of our dependency tree and work
up:
1) release all action runtimes that have changed since their last
Apache release.
2) release cli tooling
3) release event providers
4) release core system (with pinned versions of runtimes, cli, and
providers)
5) release packaging projects (kube-deploy, dev-tools, etc.) with
pinned versions of entire system.
I would also like to propose that although we keep semantic versioning of
the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, etc),
that we adopt a date-based version number for the consolidate uber-release
(eg OpenWhisk 19.01 if we actually manage to get this all out in January).
Opinions?
--dave
Re: time for next OpenWhisk release wave?
Posted by Carlos Santana <cs...@gmail.com>.
I agree so we can start with first wave
All runtimes repo, start a DISCUSS email thread to see if there is no objections to take what’s is currently the last commit on each of the runtime repos.
If discuss is ok then next start creating the tgz for them and send the VOTE for dev list.
- Carlos Santana
@csantanapr
> On Jan 24, 2019, at 9:57 AM, David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> Carlos Santana <cs...@gmail.com> wrote on 01/23/2019 05:57:16 PM:
>>
>> I also vote for a git issue with checkboxes and deal with comments as we
>> progress
>>
>
> I created [1]. By my count a "complete" release would contain at least 21
> github repos (and I may have missed some; please add them).
>
> Will need some thought on how best to stage this to minimize the number of
> rounds of voting we need. First step is to just get to a releasable
> version of each repo...
>
> --dave
>
> [1] https://github.com/apache/incubator-openwhisk-release/issues/241
Re: time for next OpenWhisk release wave?
Posted by David P Grove <gr...@us.ibm.com>.
Carlos Santana <cs...@gmail.com> wrote on 01/23/2019 05:57:16 PM:
>
> I also vote for a git issue with checkboxes and deal with comments as we
> progress
>
I created [1]. By my count a "complete" release would contain at least 21
github repos (and I may have missed some; please add them).
Will need some thought on how best to stage this to minimize the number of
rounds of voting we need. First step is to just get to a releasable
version of each repo...
--dave
[1] https://github.com/apache/incubator-openwhisk-release/issues/241
Re: time for next OpenWhisk release wave?
Posted by Carlos Santana <cs...@gmail.com>.
The release notes can also be done in the release repo short bullet of most
important changes since the last release.
Having release note is not required by the way but nice to have.
I also vote for a git issue with checkboxes and deal with comments as we
progress
On Wed, Jan 23, 2019 at 5:51 PM David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> Carlos Santana <cs...@gmail.com> wrote on 01/23/2019 05:16:15 PM:
> >
> > Is it just a matter of creating a branch "1.13.0-incubating" on the repo
> > and adding a RELEASE.md file?
> >
>
> Maybe just a CHANGELOG file on master? I think for at least some of the
> runtime repos we more or less have this already. Other repos have been
> less methodical and someone who has the knowledge will need to
> reconstruct/generate from git history.
>
> Not really sure how best to go about this or how much practical value there
> is in having detailed release notes.
>
> --dave
>
--
Carlos Santana
<cs...@gmail.com>
Re: time for next OpenWhisk release wave?
Posted by David P Grove <gr...@us.ibm.com>.
Carlos Santana <cs...@gmail.com> wrote on 01/23/2019 05:16:15 PM:
>
> Is it just a matter of creating a branch "1.13.0-incubating" on the repo
> and adding a RELEASE.md file?
>
Maybe just a CHANGELOG file on master? I think for at least some of the
runtime repos we more or less have this already. Other repos have been
less methodical and someone who has the knowledge will need to
reconstruct/generate from git history.
Not really sure how best to go about this or how much practical value there
is in having detailed release notes.
--dave
Re: time for next OpenWhisk release wave?
Posted by Carlos Santana <cs...@gmail.com>.
I agree with the plan Rodric
Dave,
What are your thinking for release notes? do you want to create the first
one for one of the runtimes? I can create the other ones.
Is it just a matter of creating a branch "1.13.0-incubating" on the repo
and adding a RELEASE.md file?
-- Carlos
On Wed, Jan 23, 2019 at 4:48 PM Rodric Rabbah <ro...@gmail.com> wrote:
> Following up on this after watching today's community call replay. Dave
> made the point that the big chunk of work toward this release is writing
> release notes and deciding which of the components is ready. Several people
> volunteered (Carlos, Matt) and I’m volunteering myself as well.
>
> I’d suggest we create an issue for each repo that we will include in the
> release to deliver the release notes to start.
>
> Dave also pointed out that there’s a few staging phases to coordinate
> which could take us about 3 weeks (largely because of the voting and 72hr
> waiting periods).
>
> Dave: what else did I miss?
>
> -r
>
> > On Jan 7, 2019, at 4:55 PM, David P Grove <gr...@us.ibm.com> wrote:
> >
> >
> >
> > I would like to see us push out a consolidated next release in the near
> > future (by end of January?). I'd also like to see us attempt to
> establish
> > a regular cadence of such consolidated releases (perhaps quarterly?).
> >
> > We would start this release from the leaves of our dependency tree and
> work
> > up:
> > 1) release all action runtimes that have changed since their last
> > Apache release.
> > 2) release cli tooling
> > 3) release event providers
> > 4) release core system (with pinned versions of runtimes, cli, and
> > providers)
> > 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> > pinned versions of entire system.
> >
> > I would also like to propose that although we keep semantic versioning of
> > the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c,
> etc),
> > that we adopt a date-based version number for the consolidate
> uber-release
> > (eg OpenWhisk 19.01 if we actually manage to get this all out in
> January).
> >
> > Opinions?
> >
> > --dave
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: time for next OpenWhisk release wave?
Posted by Rodric Rabbah <ro...@gmail.com>.
> We probably should also create an umbrella issue in the release-repo with a
> checklist or something to list all the repos we are releasing, what
> release/voting wave they are going in, and how is responsible for deciding
> they are ready. Or we could do the overall planning in the wiki. Either
> could work.
I’d prefer an issue myself with checkboxes.
-r
Re: time for next OpenWhisk release wave?
Posted by David P Grove <gr...@us.ibm.com>.
Rodric Rabbah <ro...@gmail.com> wrote on 01/23/2019 04:48:35 PM:
>
> Following up on this after watching today's community call replay.
> Dave made the point that the big chunk of work toward this release
> is writing release notes and deciding which of the components is
> ready. Several people volunteered (Carlos, Matt) and I’m
> volunteering myself as well.
>
> I’d suggest we create an issue for each repo that we will include in
> the release to deliver the release notes to start.
Makes sense.
We probably should also create an umbrella issue in the release-repo with a
checklist or something to list all the repos we are releasing, what
release/voting wave they are going in, and how is responsible for deciding
they are ready. Or we could do the overall planning in the wiki. Either
could work.
>
> Dave also pointed out that there’s a few staging phases to
> coordinate which could take us about 3 weeks (largely because of the
> voting and 72hr waiting periods).
>
> Dave: what else did I miss?
>
The other piece is to update the release scripts to understand an "uber
release" like 19.2-incubating. I was hoping this would be trivial, but
there's more machinery involved than I had anticipated.
--dave
> -r
>
> > On Jan 7, 2019, at 4:55 PM, David P Grove <gr...@us.ibm.com> wrote:
> >
> >
> >
> > I would like to see us push out a consolidated next release in the near
> > future (by end of January?). I'd also like to see us attempt to
establish
> > a regular cadence of such consolidated releases (perhaps quarterly?).
> >
> > We would start this release from the leaves of our dependency tree and
work
> > up:
> > 1) release all action runtimes that have changed since their last
> > Apache release.
> > 2) release cli tooling
> > 3) release event providers
> > 4) release core system (with pinned versions of runtimes, cli, and
> > providers)
> > 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> > pinned versions of entire system.
> >
> > I would also like to propose that although we keep semantic versioning
of
> > the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c,
etc),
> > that we adopt a date-based version number for the consolidate
uber-release
> > (eg OpenWhisk 19.01 if we actually manage to get this all out in
January).
> >
> > Opinions?
> >
> > --dave
>
Re: time for next OpenWhisk release wave?
Posted by Rodric Rabbah <ro...@gmail.com>.
Following up on this after watching today's community call replay. Dave made the point that the big chunk of work toward this release is writing release notes and deciding which of the components is ready. Several people volunteered (Carlos, Matt) and I’m volunteering myself as well.
I’d suggest we create an issue for each repo that we will include in the release to deliver the release notes to start.
Dave also pointed out that there’s a few staging phases to coordinate which could take us about 3 weeks (largely because of the voting and 72hr waiting periods).
Dave: what else did I miss?
-r
> On Jan 7, 2019, at 4:55 PM, David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> I would like to see us push out a consolidated next release in the near
> future (by end of January?). I'd also like to see us attempt to establish
> a regular cadence of such consolidated releases (perhaps quarterly?).
>
> We would start this release from the leaves of our dependency tree and work
> up:
> 1) release all action runtimes that have changed since their last
> Apache release.
> 2) release cli tooling
> 3) release event providers
> 4) release core system (with pinned versions of runtimes, cli, and
> providers)
> 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> pinned versions of entire system.
>
> I would also like to propose that although we keep semantic versioning of
> the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, etc),
> that we adopt a date-based version number for the consolidate uber-release
> (eg OpenWhisk 19.01 if we actually manage to get this all out in January).
>
> Opinions?
>
> --dave
Re: time for next OpenWhisk release wave?
Posted by Rodric Rabbah <ro...@gmail.com>.
i like it.
On Mon, Jan 7, 2019 at 10:03 PM David P Grove <gr...@us.ibm.com> wrote:
>
>
> I would like to see us push out a consolidated next release in the near
> future (by end of January?). I'd also like to see us attempt to establish
> a regular cadence of such consolidated releases (perhaps quarterly?).
>
> We would start this release from the leaves of our dependency tree and work
> up:
> 1) release all action runtimes that have changed since their last
> Apache release.
> 2) release cli tooling
> 3) release event providers
> 4) release core system (with pinned versions of runtimes, cli, and
> providers)
> 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> pinned versions of entire system.
>
> I would also like to propose that although we keep semantic versioning of
> the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, etc),
> that we adopt a date-based version number for the consolidate uber-release
> (eg OpenWhisk 19.01 if we actually manage to get this all out in January).
>
> Opinions?
>
> --dave
>
Re: time for next OpenWhisk release wave?
Posted by Matt Rutkowski <mr...@apache.org>.
Thanks Dave, I too really like your idea for using a year.month[.x] format for the uber release. I do wonder how the concept of an uber release would work with the Incubator (as well as its label). In addition, a tracking issue for the release notes with checks for each repo. (signoff) also seems like a good sugg.
On 2019/01/07 21:55:12, "David P Grove" <gr...@us.ibm.com> wrote:
>
>
> I would like to see us push out a consolidated next release in the near
> future (by end of January?). I'd also like to see us attempt to establish
> a regular cadence of such consolidated releases (perhaps quarterly?).
>
> We would start this release from the leaves of our dependency tree and work
> up:
> 1) release all action runtimes that have changed since their last
> Apache release.
> 2) release cli tooling
> 3) release event providers
> 4) release core system (with pinned versions of runtimes, cli, and
> providers)
> 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> pinned versions of entire system.
>
> I would also like to propose that although we keep semantic versioning of
> the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, etc),
> that we adopt a date-based version number for the consolidate uber-release
> (eg OpenWhisk 19.01 if we actually manage to get this all out in January).
>
> Opinions?
>
> --dave
>
Re: time for next OpenWhisk release wave?
Posted by Carlos Santana <cs...@gmail.com>.
+1
It’s time to cut releases, the CLI now has wskdeploy function so it should
be good to have a versioned out for it.
For the runtimes there has being new la gauge versions also good to
release.
I like the uber version using time based this is how docker is doing theirs
like “18.09.00”
On Tue, Jan 8, 2019 at 2:55 AM Rob Allen <ro...@akrabat.com> wrote:
> Hi,
>
> This sounds good to me.
>
> I particularly like the idea of a year.month version number for the
> overall distribution as it works well with each component having its own
> release numbering.
>
>
> Regards,
>
> Rob
>
> > On 7 Jan 2019, at 21:55, David P Grove <gr...@us.ibm.com> wrote:
> >
> >
> >
> > I would like to see us push out a consolidated next release in the near
> > future (by end of January?). I'd also like to see us attempt to
> establish
> > a regular cadence of such consolidated releases (perhaps quarterly?).
> >
> > We would start this release from the leaves of our dependency tree and
> work
> > up:
> > 1) release all action runtimes that have changed since their last
> > Apache release.
> > 2) release cli tooling
> > 3) release event providers
> > 4) release core system (with pinned versions of runtimes, cli, and
> > providers)
> > 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> > pinned versions of entire system.
> >
> > I would also like to propose that although we keep semantic versioning of
> > the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c,
> etc),
> > that we adopt a date-based version number for the consolidate
> uber-release
> > (eg OpenWhisk 19.01 if we actually manage to get this all out in
> January).
> >
> > Opinions?
> >
> > --dave
>
> --
> Development thoughts at http://akrabat.com
> Daily Jotter for macOS at http://dailyjotter.com
>
> --
Carlos Santana
<cs...@gmail.com>
Re: time for next OpenWhisk release wave?
Posted by Rob Allen <ro...@akrabat.com>.
Hi,
This sounds good to me.
I particularly like the idea of a year.month version number for the overall distribution as it works well with each component having its own release numbering.
Regards,
Rob
> On 7 Jan 2019, at 21:55, David P Grove <gr...@us.ibm.com> wrote:
>
>
>
> I would like to see us push out a consolidated next release in the near
> future (by end of January?). I'd also like to see us attempt to establish
> a regular cadence of such consolidated releases (perhaps quarterly?).
>
> We would start this release from the leaves of our dependency tree and work
> up:
> 1) release all action runtimes that have changed since their last
> Apache release.
> 2) release cli tooling
> 3) release event providers
> 4) release core system (with pinned versions of runtimes, cli, and
> providers)
> 5) release packaging projects (kube-deploy, dev-tools, etc.) with
> pinned versions of entire system.
>
> I would also like to propose that although we keep semantic versioning of
> the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, etc),
> that we adopt a date-based version number for the consolidate uber-release
> (eg OpenWhisk 19.01 if we actually manage to get this all out in January).
>
> Opinions?
>
> --dave
--
Development thoughts at http://akrabat.com
Daily Jotter for macOS at http://dailyjotter.com