Rodric Rabbah <[email protected]> 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 <[email protected]> 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 >
