Hi Dave, > As it is, the 0.9.0 release is only useful for practice with the Apache > release process. The various source artifacts tagged 0.9.0 are not > actually compatible with each other.
I am upset if you say this. I have been working my bones out during the past months to make sure openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube under 0.9.x version matching, and they work together. As long as the runtimes work ok with them, they are good to release even in one tar.gz to work as the openwhisk platform. 0.9.0 is not just an Apache practice. I know it is not perfect and has tons of things to improve it, but I have already tried my best. At the beginning, I hope all the modules including runtimes can have 0.9.0, so that all of them can release in one tar.gz, which is the basic standard I set for openwhisk to release for the first time under Apache. We are RELEASING really "intellectual asset" under Apache, that people can use. Not for practice with the Apache release process. Best wishes. Vincent Hou (侯胜博) Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: [email protected], Phone: +1(919)254-7182 Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States -----"David P Grove" <[email protected]> wrote: ----- To: [email protected] From: "David P Grove" <[email protected]> Date: 08/27/2018 01:46PM Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache Justin Halsall <[email protected]> wrote on 08/27/2018 01:16:41 PM: > > I recently bumped into docker-compose always pulling in the latest > version of our containers but then failing because we had changed > some of the dependent variables in the docker image but forgot to do > so in our Docker Compose configuration files. With the centralized > runtime manifest we could easily lock our deployments (including > docker compose) to a release version with limited hassle. > Also been thinking about this. We do have a central manifest already (runtime.json + ansible group_vars/all in the core project). The mistake we made is that we left all these tags at "latest" in the 0.9.0 release (arguably because there had not been a release of the sub-projects yet, so there was nothing else to use as a tag value). In future releases, we need to first officially release any of the "leaf" projects that aren't current, then branch the core repo into a release branch, then commit a version of runtime.json (and other ansible files) on this branch that pulls from a fixed tag (not latest) for all the other projects. Same thing for the kube-deploy, docker-compose, etc. -- branch, commit fixed tags for images, then release. As it is, the 0.9.0 release is only useful for practice with the Apache release process. The various source artifacts tagged 0.9.0 are not actually compatible with each other. --dave
