If we want to backport this, at the moment I think it is the only option. Our current process is quite dependent on the current state of main and the CI fixes for the rest of jobs / verifications / etcetera. So, in my opinion, cherry-picking this commit into a 12.0.2 tag for Go and running the source verification for Go, as we did in the past, is the approach we should take.
I am ok with that approach. Raúl El lun, 15 abr 2024 a las 19:52, Matt Topol (<zotthewiz...@gmail.com>) escribió: > > Hey all, > > There was a request to backport a fix for Go Arrow from v13 back to v12 [1] > to improve a dependency situation for a user of Go Arrow where the > databricks-sql-go driver is using Arrow v12 currently, thus exhibiting the > bug they want to backport a fix for. To be fair, they have also made a > request for databricks to simply update their version of Arrow [2]. > > Since Go only requires a git tag to "release" rather than any binary > artifact results, in the past we've done a patch release for Go by simply > creating the tag and uploading the source tarball [3] significantly > reducing the cost of performing the release itself. > > Assuming a vote passes, I wanted to take a pulse on opinions as to > backporting and releasing a v12.0.2 for Go and if anyone would oppose such > a thing. > > Thanks everyone! > > --Matt > > [1]: https://github.com/apache/arrow/issues/41156 > [2]: https://github.com/databricks/databricks-sql-go/pull/216 > [3]: https://lists.apache.org/thread/lt8dp0dxtcvkkz7k6wyhdjcwb5yzbvll
