openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David P Grove" <gro...@us.ibm.com>
Subject Re: [DISCUSSION]: Release plan of OpenWhisk 0.9.0 for all modules
Date Mon, 06 Aug 2018 15:29:56 GMT



"Vincent S Hou" <shou@us.ibm.com> wrote on 08/03/2018 11:42:56 AM:
>
> In order to keep you on the same page, I will discuss my release
> plan for openwhisk 0.9.0 of all the 13 modules.
>
> As you know, we have already released OpenWhisk main module for
> Version 0.9.0 in Apache for the first time. There are still 12 other
> modules/projects on the roadmap. I would like to release the rest of
> them in groups:
>
> * client go and cli as a group,
> * catalog and apigateway as a group,
> * wskdeploy and deploy cube as a group,
> * Nodejs, Java and Swift runtimes as a group,
> * Docker, Php and Python as a group,
>
> till all the modules are released under 0.9.0, which means I will
> send out emails for votes based on different groups. Please prepare
> for them. I expect another month to release all the rest modules, on
> top of main module.
>


Hi Vincent,

	Releasing in groups makes sense to me to reduce the number of VOTE
email chains.

	However, I do not think it is desirable to release the various
runtimes with a 0.9.0-incubating version number.  This is going to be
confusing to users because there are already "nightly snapshot" tags with
version numbers greater than 0.9.0 for all of the runtime git repos.   I
think instead we should be making official Apache releases with numbering
schemes that are compatible with the most recent pre-existing snapshot tag
for each runtime.   For example, openwhisk-runtime-python-1.0.2-incubating
for the Python runtime (or 1.0.3 if we want/need to bump the minor number
to pick up the latest master branch in the official release).
	We expect the runtimes will be released on independent cadences in
the future, so the version numbers aren't going to stay synchronized with
each other (or the core system).  So I don't see that we should try to
force a uniform starting number now.

regards,

--dave

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message