You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@skywalking.apache.org by Sheng Wu <wu...@gmail.com> on 2019/11/17 08:37:04 UTC
[Release] Prepare for Helm release process. NOTICE for CLI sub project.
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
Re: [Release] Prepare for Helm release process. NOTICE for CLI sub project.
Posted by hw zhai <in...@gmail.com>.
Agree, thanks .
Re: [Release] Prepare for Helm release process. NOTICE for CLI sub project.
Posted by Sheng Wu <wu...@gmail.com>.
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 <in...@gmail.com> 于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 <wu...@gmail.com> 于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 <in...@gmail.com> 于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 <wu...@gmail.com> 于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
> > > >
> > >
> >
>
Re: [Release] Prepare for Helm release process. NOTICE for CLI sub project.
Posted by hw zhai <in...@gmail.com>.
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 <wu...@gmail.com> 于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 <in...@gmail.com> 于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 <wu...@gmail.com> 于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
> > >
> >
>
Re: [Release] Prepare for Helm release process. NOTICE for CLI sub project.
Posted by Sheng Wu <wu...@gmail.com>.
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 <in...@gmail.com> 于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 <wu...@gmail.com> 于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
> >
>
Re: [Release] Prepare for Helm release process. NOTICE for CLI sub project.
Posted by hw zhai <in...@gmail.com>.
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 <wu...@gmail.com> 于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
>