So, you want 1. The master branch is only including the latest helm. 2. Current master with multiple versions moves to the legacy branch 3. One release of the helm chart repo is only for one main repo release.
If above are right, make sense to me. I just have a question for your version number rule. Because the helm chart may have bugs or missing some configurations, so you may want to release more versions for one sw release. Maybe the version number can't match the release version. You may need to put the version match in the documentations, and helm readme. What do you think? Sheng Wu 吴晟 Twitter, wusheng1108 hw zhai <[email protected]> 于2019年11月18日周一 下午2:15写道： > Hi Sheng Wu > > Thank for your help . > > I want to move the corresponding chart of 6.0.0 ~ 6.4.0 to the > corresponding branch, leaving only one version of the chart in the master > branch. > The follow-up is not to create a new branch, but to determine the version > by means of the release tag. > > Starting with SW 6.5.0, the version of chart starts at 1.0.0, and the > following rules are as follows： > > sw 6.6.0 -> chart 1.1.0 > sw 7.0.0 -> chart 2.0.0 > > Do you have any different suggestions about the version? > > Sheng Wu <[email protected]> 于2019年11月17日周日 下午4:37写道： > > > Hi Hongwei Zhai > > > > Thanks for you to propose the helm repo official release process. As I > have > > been a release manager from day one, I could help you about this. > > > > For an Apache release, first of you, you need to prepare the following > > things > > 1. Decide which part of you are going to release. From GitHub repo, set > up > > the tag and generate source tar. > > 2. Source tar should include the helm chart for particular version(s), > how > > many version supported depend on your decision. All files should include > > the Apache 2.0 header, please add a CI to test it, such as GitHub action. > > 3. LICENSE and NOTICE file are required, as we don't include any 3rd > party > > things, should be the standard LICENSE[1] and NOTICE[2]. > > 4. Package helm source files, LICENSE, NOTICE and doc into the source > tar. > > With PGP sign, sha512. Read this[3] about pgp, and sha512 is easy, us > this > > command, shasum -a 512 file > file.sha512 > > 5. Set up your version policy, > > 6. Upload all files into svn, > > https://dist.apache.org/repos/dist/dev/skywalking/ + helm + version. > > 7. Organize the test mail, vote mail, result mail. > > 8. Move the svn release RC to > > https://dist.apache.org/repos/dist/release/skywalking/ + helm + version. > > 9. Organize annoucement mail and twitter > > > > These steps may be long, but not complex. > > > > For you, maybe test will become a high priority job, because only you and > > Gao are working on this. We may need to invite more people to test, and > > report the feedback from the community. And setting up the CI tests is > > important. > > But this is not a block, just a reminder. > > > > Zhengxu Ke, Wei Zhang and all CLI team, > > These steps are related to your potential CLI release too. > > > > > > [1] http://apache.org/licenses/LICENSE-2.0.txt > > [2] http://www.apache.org/dev/licensing-howto.html#simple > > [3] > > > > > https://github.com/apache/skywalking/blob/master/docs/en/guides/How-to-release.md#add-your-gpg-public-key > > > > Sheng Wu 吴晟 > > Twitter, wusheng1108 > > >
