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 <[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 -- Development thoughts at http://akrabat.com Daily Jotter for macOS at http://dailyjotter.com
