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>
>> >> >
>> >>
>>
