Make sense to me. After you move the current master to a new branch, maybe called `legacy-helm-chart`, you should submit a JIRA ticket[1] to the ASF INFRA team, request for branch protection for `master` and `legacy-helm-chart`. (Select `Infrastructure (INFRA)` as the project in JIRA issue, and indicate project, repo, and branches) All changes should go through a pull request, agree?
[1] https://issues.apache.org/jira/secure/Dashboard.jspa Sheng Wu 吴晟 Twitter, wusheng1108 hw zhai <[email protected]> 于2019年11月18日周一 下午2:57写道： > The three points are right. I want to do these. > > About helm version , fix bug version , I want to use the last number as the > fix version number. > For example: > sw 6.5.1 -> chart 1.0.1 > sw 6.6.0 -> chart 1.1.0 > sw 6.6.1 -> chart 1.1.1 > > Or if it is a bug modification of chart itself, increase the last number. > For example: > sw 6.6.1 -> chart 1.1.1 > sw 6.6.1 -> chart 1.1.2 > sw 6.6.2 -> chart 1.1.3 > > and record corresponding version in the introduction of release. > > Finally add the document of version for users to quickly find the > corresponding version. > > Sheng Wu <[email protected]> 于2019年11月18日周一 下午2:31写道： > > > 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 > > > > > > > > > >
