Hi Weiwei, Do we really need another repo for three files? We should sleep track of this in the core repo not in another repo which we need to release manage again. I think managing the release from the core repo will make it easier later on if we need to or want to change the build process further. Now we need need to manage and track soo many repos that it becomes more and more difficult. We also need to keep in mind that version information is in the module files. There might thus be more that needs to change for a release. The other thing is that we might not want to release a new version of one of the components while updating another component. That would means that we need to release manage 5 repositories for one release, including all the overhead.
Apache releases are source releases. We still need to provide some kind of make etc over the source code also. I agree with the fact that we need to provide one source archive that is signed. However with the current build process just the k8shim code is enough to build the docker image. The other code repos will be pulled in from github. The mod file point there for all go dependencies including the core and SI. It does not provide any detail on the how and what for any of the repos. We need to provide some build instructions in the root of the source archive. I would not know how to build from the source package if we just add the checked out code into it. We need to provide some steps even if they are just pointers to existing docs. I also don't think we have the correct files in the archive with the current generated archive. Wilfred > On Mon, 13 Apr 2020 at 14:01, Weiwei Yang <[email protected]> wrote: > For 0.8 release, I did some work and I wanted to share the latest status. I > think we should target for *docker-image-based* release mode. I propose to > release a unified open-source tarball, we don't release a binary tarball > (not a must [1]). Things have been *DONE*: > > 1. I have created a repo for release mgmt: > https://github.com/yangwwei/yunikorn-release, I think we need to move > this to apache repo too. > 2. This repo has the instructions and tools for a release. The tool > loads configs from > > https://github.com/yangwwei/yunikorn-release/blob/master/tools/release-configs.json > and > downloads source code from certain repo/branch/hash to assemble the > release > artifacts 3. This repo contains a *build-docker-image.sh* to build yunikorn docker > images (scheduler, admission-controller, and web) > 4. I have created *branch-0.8* for all 4 repos > 5. The generated tarball will also have the helm chart for user to > install and run yunikorn on an existing K8s cluster > 6. I tried to generate PGP key and sign the tarball > > Things *TODO* > > 1. Create a repo for yunikorn-release under ASF > 2. IIUC, https://issues.apache.org/jira/browse/YUNIKORN-79 is a blocker > for 0.8. Can we get this fixed ASAP? > 3. Once #2 is done, create a tag for 0.8-rc1 and start the voting thread > > Thanks! > > [1] https://infra.apache.org/release-publishing.html *The Apache Software > Foundation exists to create open source software, so the fundamental > requirement for a release is that it has the necessary source code to build > the project. A project may provide compiled binaries of each release for > the convenience of users.* >
