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" <[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 >
