Hi, It seems that there are no objections for this release plan.
I've prepared 6.0.2, 7.0.1 and 8.0.1. I'll start votes for them. Thanks, -- kou In <20220708.110101.1989678110062934069....@clear-code.com> "Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948" on Fri, 08 Jul 2022 11:01:01 +0900 (JST), Sutou Kouhei <k...@clear-code.com> wrote: > Hi, > > It seems that there are no objections for these patch releases. > > I'll initiate these patch releases. Here is my plan. If > there are any objections/concerns, please share them. > > * We'll release 6.0.2, 7.0.1 and 8.0.1 > * These releases only include > https://github.com/apache/arrow/pull/13322 > * We'll create apache-arrow-6.0.2.tar.gz, > apache-arrow-7.0.1.tar.gz and > apache-arrow-8.0.1.tar.gz as usual > * These tar.gz include not only go/ but also all languages > in apache/arrow to reuse the current release script > * We'll not create binary artifacts for 6.0.2, 7.0.1 and > 8.0.1 because we don't have binary artifacts relate to Go > * We'll start votes for releasing 6.0.2, 7.0.1 and 8.0.1 > > > Thanks, > -- > kou > > In <CAH4123b5vROsB7rqcgKXp-FX==bbhjbpby9vzn5giq7_zo8...@mail.gmail.com> > "Re: [Go][Release][Discussion] Patch release for Go libraries to address > CVE-2022-28948" on Mon, 13 Jun 2022 19:24:16 -0400, > Matt Topol <zotthewiz...@gmail.com> wrote: > >>> I'm also not an expert but I think that we need to "release" >>> (vote) a patch version. (I think that just doing "git tag" >>> isn't suitable.) >> >> I was figuring there would need to be a vote, and as I'm not part of the >> PMC I didn't know whether it was my place to attempt to call such a vote. >> :) Would we need three separate votes? (One for v6.0.2, v.7.0.1, and one >> for v8.0.1) >> >>> We can't mark 8.0.1 as official unless we "release" 8.0.1. >> >> Can we *just* "release" the Go patch releases (like the arrow-rs rust >> library seems to be doing)? Or do we need to fully release all the >> languages for consistency (which is what I assume is the case)? >> >>> Again, I'm also not an expert. I hope that others comment on >>> this too. >> >> Same. This isn't exactly something I can pretend to be very familiar with >> particularly as a policy decision. Hopefully others will comment and >> respond to this. >> >> --Matt >> >> On Sun, Jun 12, 2022 at 10:06 PM Sutou Kouhei <k...@clear-code.com> wrote: >> >>> Hi, >>> >>> I'm also not an expert but I think that we need to "release" >>> (vote) a patch version. (I think that just doing "git tag" >>> isn't suitable.) >>> >>> Because we need to "release" to announce users to use >>> "go/v8.0.1" rather than "go/v8.0.0": >>> >>> https://www.apache.org/legal/release-policy.html#publication >>> >>> > Projects SHALL publish official releases and SHALL NOT >>> > publish unreleased materials outside the development >>> > community. >>> >>> We can't mark 8.0.1 as official unless we "release" 8.0.1. >>> >>> (I understand that Go doesn't need released materials. Go >>> just needs a Git tag. I understand that the ASF's release >>> policy isn't suitable for recent languages such as Go and >>> Julia. Micah started a discussion it in another place. The >>> ASF's release policy may be updated in future.) >>> >>> >>> But we don't need to release binary artifacts because we >>> don't have any binary artifacts for Go. We can just release >>> a source archive for patch releases of this. >>> >>> >>> Again, I'm also not an expert. I hope that others comment on >>> this too. >>> >>> >>> Thanks, >>> -- >>> kou >>> >>> In <caocv4hhmex-bah1gha727zplb-mg+fq2twz3cqn+aw1wuax...@mail.gmail.com> >>> "Re: [Go][Release][Discussion] Patch release for Go libraries to address >>> CVE-2022-28948" on Fri, 10 Jun 2022 11:43:26 -0400, >>> Neal Richardson <neal.p.richard...@gmail.com> wrote: >>> >>> > Personally, I don't have a problem with doing `git tag` just for Go. I >>> > don't think this needs a full patch release process since we aren't >>> > producing new artifacts that need signing, we're only adding a tag that >>> > points to a SHA in git. But I am not an expert in this area of policy and >>> > will defer to others who know better. >>> > >>> > Neal >>> > >>> > >>> > On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zotthewiz...@gmail.com> >>> wrote: >>> > >>> >> I've merged the PR to master and want to propose cherry-picking it to >>> >> create patch releases. Technically, for Go, all we need to do is create >>> the >>> >> appropriate tags named like "go/v6.0.2", and so on. Since this >>> >> vulnerability only affects Go we don't necessarily need to release >>> patches >>> >> for the other language libraries other than for consistency. >>> >> >>> >> So I guess I'd like others to chime in on opinions as to whether we >>> should >>> >> just cherry-pick and create the tags just for patch releases for Go or >>> do >>> >> full patch releases of everything for consistency. >>> >> >>> >> --Matt >>> >> >>> >> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes >>> <dobar...@twilio.com.invalid >>> >> > >>> >> wrote: >>> >> >>> >> > Howdy! >>> >> > >>> >> > I'm a first-time contributor, and I just opened a PR to update a >>> dev/test >>> >> > dependency (github.com/stretchr/testify) to address a security >>> >> > vulnerability being reported downstream: >>> >> > >>> >> > https://github.com/apache/arrow/pull/13322 (more context included >>> here) >>> >> > >>> >> > The PR was originally opened against the release-v7.0.0 branch, but I >>> was >>> >> > then pointed towards using master instead, with the intention of >>> >> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases. >>> >> > >>> >> > While not merged yet, it sounded like I should get the ball rolling >>> now. >>> >> > Let me know how I can help get this across the finish line. >>> >> > >>> >> > -- >>> >> > Dominic Barnes >>> >> > >>> >> > he/him/his >>> >> > Staff Software Engineer >>> >> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature> >>> >> > EMAIL dobar...@twilio.com >>> >> > TWITTER @mako281 <https://twitter.com/mako281> >>> >> > GITHUB dominicbarnes <https://github.com/dominicbarnes> >>> >> > >>> >> >>>
