openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject Re: publishing developer-oriented binary artifacts
Date Wed, 12 Dec 2018 17:29:49 GMT
Thanks Dave for consolidating the various points of discussion. This is very helpful and the
thoughtful recommendations. I agree on all parts with your assessment and direction, and will
help out on driving the releases so we can get to a more cogent point. 


> On Dec 12, 2018, at 9:16 AM, David P Grove <> wrote:
> We have related conversations on mail threads [1] and [2].  I suggest we
> consolidate to a new thread to nail down a policy that we can document.  I
> suspect it is pretty close to what we are operationally doing already, but
> we need to write it down.
> 1. Publishing on dockerhub.
>  a.  I suggest we only have one official dockerhub user, openwhisk.
> Having multiple dockerhub accounts publishing on behalf of the project is
> more likely to cause confusion about which images are sanctioned.
>  b.  We should be uniformly tagging all developer-focused "nightly" docker
> images with a git short hash (as done by the runtimes and core repo
> already).  This makes it very clear these are nightly/developer builds and
> not sanctioned releases.
>  c.  We should reserve the use of x.y.z semantic version tags for docker
> images that exactly correspond to an official Apache Source Release.
>  d. Because of (c), we should be making more frequent Apache releases,
> especially of the runtimes.  Our release automation process makes this only
> moderately burdensome and the more we use it, the easier it will become.
> 2.  Publishing the wsk and wskdeploy clis
>  a. I think Carlos has mostly covered this in [3].   Key point is the
> reservation of semantic versioning x.y.z tags to artifacts that correspond
> to official Apache releases.
>  b. I do think it might be useful to preserve some number of previous
> git-hash tagged interim releases of the clis, instead of always overwriting
> 'latest', but perhaps this is harder to automate.
>  c. Again, we probably need to be making more frequent official Apache
> source releases to provide the source artifacts that can generate
> convenience binaries with x.y.z versions in a reasonable cadence.
> 3. Publishing on maven, npmjs, PyPI, etc.
>  a. Same basic principles, only artifacts that are directly derived from
> an Apache source release can use semantic versioning tags.
>  b. To the extent supported by the package repository, we have a single
> official project account for publishing artifacts.
>  --dave
> [1]
> [2]
> [3]

View raw message