You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by David P Grove <gr...@us.ibm.com> on 2018/12/12 17:16:58 UTC
publishing developer-oriented binary artifacts
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]
https://lists.apache.org/thread.html/05ab690fc0c2acc17103dd183262180efaf27cdd78c49cc35c48f659@%3Cdev.openwhisk.apache.org%3E
[2]
https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E
[3]
https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E
Re: publishing developer-oriented binary artifacts
Posted by Rodric Rabbah <ro...@gmail.com>.
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.
-r
> On Dec 12, 2018, at 9:16 AM, David P Grove <gr...@us.ibm.com> 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]
> https://lists.apache.org/thread.html/05ab690fc0c2acc17103dd183262180efaf27cdd78c49cc35c48f659@%3Cdev.openwhisk.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E
> [3]
> https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E