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