openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David P Grove" <gro...@us.ibm.com>
Subject Re: time for next OpenWhisk release wave?
Date Wed, 23 Jan 2019 22:38:00 GMT


Rodric Rabbah <rodric@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 <groved@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
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message