+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 <[email protected]> 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 <[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 > > -- Carlos Santana <[email protected]>
