As far as I know, OpenWhisk has a big issue with the versioning we cannot disregard.
OpenWhisk runs as a whole platform, which consists of multiple projects/modules. The optimal pattern is that all the modules release at a time with the same version number, so that we can match them, and we know under this certain version number, all the modules will work together. Right now, we have the following modules under 0.9.0 or at least 0.9.X openwhisk openwhisk-catalog, openwhisk-client-go openwhisk-cli, openwhisk-wskdeploy, openwhisk-deploy-kube, openwhisk-apigateway I plan bundle all of them together in one tar.gz, so that they can be downloaded in one compressed file for convenience. I suggest and insist that at least 7 of these modules can keep up the same version and able to be released synchronously in future, because OpenWhisk is so far a platform, depending on multiple modules to release. If we mismatch the version numbers in future, how could we know whether 1.2.0 CLI is able to run on top of 1.1.0 openwhisk?? The same issue will happen to runtimes as well. How do we know if 1.13.0 nodejs can match the 1.1.0 openwhisk? Of course, each repository should run on its owns, and release on its own cycle. However, openwhisk is not that "INTELLIGENT" yet to do so. If we propose one version for the 6 runtimes, like 1.12.0(I wish too much it could still be 0.9.0, but as a respect for the reality, I accept it can be some other version). After they are released, we can add a document somewhere, saying that 0.9.0 openwhisk modules match 1.12.0 runtimes, and we can make sure that all the 1.12.0 runtimes able to run in 0.9.0 openwhisk with no problem. If we release runtimes individually, we should create a matrix describing like 1.12.0 nodejs, docker skeleton v1.3.3, python v1.0.3, node8 v1.12.0, php7.2 v1.0.2, swift4.1 v1.0.8, java8 v1.1.2 can really work on 0.9.0 openwhisk. As each runtime module develops, we have to keep on updating this matrix. Is this something we love to have? Or is there a better way to do it? Based on the reality, why don't we get the first release of all the modules of openwhisk out for the first time using the easiest way? We can come up to the solution later and keep this discussion open. Otherwise, we have to resolve this issue ASAP before we release anything. 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:34PM Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache "Vincent S Hou" <[email protected]> wrote on 08/27/2018 12:39:01 PM: > > For convenience of release management in Apache. > * We can send one or two vote email(s) instead of 6. I realize that it will make the initial release more convenient. I don't think this is a compelling reason however. > * The download page of openwhisk.org can allocate one section to > offer the download links of runtimes. I don't think this is a good pattern. I predict we will be releasing runtimes in individual cadences, driven by changes in the upstream base language runtime, CVEs that need to be fixed via a new runtime release, etc. So I think the download for the runtime needs to be organized by runtime, then by version within each runtime, not by openwhisk version. --dave > > > > 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 > > -----Rodric Rabbah <[email protected]> wrote: ----- > To: [email protected] > From: Rodric Rabbah <[email protected]> > Date: 08/27/2018 11:45AM > Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version > for all runtimes for the first-time release under Apache > > Why do they all need to start from the same version? > > On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <[email protected]> wrote: > > > Hi OpenWhiskers, > > > > We are on our way to release OpenWhisk runtimes under Apache for the first > > time. As you may notice or not, each individual runtime repository has > > already used > > its own version numbers as the build tag for quite a while. In order not > > to disrupt the current versioning number and also accommodating the release > > work under Apache, I would like to propose 1.12.0 as the version number for > > the first time we release the six runtimes under Apache, because this > > version number is the minimum > > nominator I find for all the runtimes so far. > > > > We now have following runtimes, which have already released with their > > version numbers: > > docker skeleton v1.3.3 > > python2 v1.0.3 > > python3 v.1.0.3 > > node8 v1.12.0 > > node6 v1.12.0 > > php7.2 v1.0.2 > > swift4.1 v1.0.8 > > java8 v1.1.2 > > > > I think 1.12.0 can match them all, and then use it as a common ground to > > move on with further version numbers. I would like to hear your comments. > > If no objection is heard, I will move on with 1.12.0 for the runtimes to > > be released under Apache for the first time. > > > > Best wishes, > > Vincent Hou > > > > > > >
