I like this idea and happy to implement this change. On Thu, Aug 8, 2024, at 00:54, Fokko Driesprong wrote: > BTW, what would also really help is having the release as a Github Action > workflow, similar to Iceberg-rust: > https://github.com/apache/iceberg-rust/blob/main/.github/workflows/publish.yml > > Kind regards, > Fokko > > Op wo 7 aug 2024 om 18:53 schreef Fokko Driesprong <fo...@apache.org>: > >> Hey xxchan, >> >> Thanks for the quick response. You're right, this is specifically for >> Rust, so sorry for the confusion. I'll raise a separate DISCUSS thread. >> >> Kind regards, >> Fokko >> >> Op wo 7 aug 2024 om 18:25 schreef xxchan <xxchan...@gmail.com>: >> >>> Hi Fokko, >>> >>> Personally I think having a patch release for the CVE fix is totally fine. >>> But do you mean release separately for Java (like proposed here for Rust), >>> or doing a normal release for all languages? >>> >>> I'm not sure what are the current main pain points in the release >>> procedure, >>> but I guess doing the former can help save maintainers' effort, as the >>> same >>> rationale raised by Xuanwo. I think an approach that helps reduce >>> maintenance >>> effort and increase release frequency will be beneficial to the community. >>> >>> BTW, I think many people in this thread are more interested in the Rust >>> package. >>> Should we just drive another VOTE for the new release directly? >>> Besides, also want to hear Martin's input about why to cherry-pick Rust >>> PRs, and >>> what's the release plan in his mind. >>> >>> xxchan >>> >>> On Wed, Aug 7, 2024 at 10:41 PM Fokko Driesprong <fo...@apache.org> >>> wrote: >>> >>> > Hey everyone, >>> > >>> > A CVE fix has been backported >>> > <https://github.com/apache/avro/pull/2980/files> to the 1.11 branch. >>> The >>> > 1.12.0 branch drops Java 8 support, and it would be good to have a >>> version >>> > released that Java 8 users can update to. How about doing this as a >>> > separate release? It looks like >>> > <https://github.com/apache/avro/commits/branch-1.11/> there are not >>> many >>> > backports for other languages (except for Rust). >>> > >>> > Let me know your thoughts >>> > >>> > Kind regards, >>> > Fokko >>> > >>> > Op vr 2 aug 2024 om 10:44 schreef Renjie Liu <liurenjie1...@apache.org >>> >: >>> > >>> > > +1 to releasing Rust separately. Our experience in rust shows that it >>> > > benefits the project well and helps to grow rust version faster. >>> > Different >>> > > people have different expertise in different languages, and it's >>> > difficult >>> > > for maintainer to know understand all languages well. >>> > > >>> > > On 2024/08/01 13:38:58 Xuanwo wrote: >>> > > > Hello, everyone >>> > > > >>> > > > I start this thread to discussion if it possible to release package >>> > > seperately, especially for some new language implemeantions like rust >>> > which >>> > > is still at pre 1.0 stage. >>> > > > >>> > > > I understand this doesn't align with the community's current >>> practices, >>> > > and I didn't thoroughly research whether this has been discussed >>> before. >>> > > > >>> > > > But I really think there are many benefits for this: >>> > > > >>> > > > - Users can receive updates more quickly and regularly. They don't >>> need >>> > > to wait for the entire avro project to release. >>> > > > - Rust implementers no longer need to cherry-pick commits, >>> > significantly >>> > > reducing their workload. The release process could be as simple as >>> tag at >>> > > main branch, vote and let CI to do publish. >>> > > > - Given the current low activity of Avro Rust, most releases for >>> Avro >>> > > are merely dependency updates. We can save some effort by aligning >>> with >>> > > avro-java's own release schedule. >>> > > > - The last point, which I believe is the most important, could >>> attract >>> > > more Avro Rust users to develop at upstream. The rust community has >>> built >>> > > avro[1], avro-rs[2], rsgen-avro[3], serde-avro-bytes[4], >>> > > serde_avro_fast[5], avro-schema[6], struct-from-avro[7], >>> serde-avro[8]. >>> > By >>> > > combining our efforts, we can significantly accelerate improvements in >>> > Avro >>> > > Rust. >>> > > > >>> > > > There are also some risks: >>> > > > >>> > > > - Implementing these changes requires extra effort from the >>> community. >>> > > > - Avro Rust releases may be less frequent because it doesn't keep up >>> > > with the main Avro repository. >>> > > > - Release rust seperately doesn't change the fact that PMC members >>> > still >>> > > need to do the work. >>> > > > >>> > > > I believe most issues can be addressed: >>> > > > >>> > > > - I have implemented the whole rust release process for OpenDAL[9] >>> and >>> > > iceberg-rust[10]. I am also willing to help build the Rust release >>> > process >>> > > for Avro. >>> > > > - That's possible, but I believe once we can get more developers >>> > > involved in developing Avro Rust, we can release more frequently >>> instead. >>> > > > - That's true, but verify rust release should be super simple with >>> > > correct tools. My experience in this area can be helpful. >>> > > > >>> > > > >>> > > > What do you think? >>> > > > >>> > > > >>> > > > [1]: https://crates.io/crates/avro >>> > > > [2]: https://crates.io/crates/avro-rs >>> > > > [3]：https://crates.io/crates/rsgen-avro >>> > > > [4]: https://crates.io/crates/serde-avro-bytes >>> > > > [5]: https://crates.io/crates/serde_avro_fast >>> > > > [6]: https://crates.io/crates/avro-schema >>> > > > [7]: https://crates.io/crates/struct-from-avro >>> > > > [8]: https://crates.io/crates/serde-avro >>> > > > [9]: https://opendal.apache.org/community/release/ >>> > > > [10]: https://rust.iceberg.apache.org/release.html >>> > > > >>> > > > Xuanwo >>> > > > >>> > > > https://xuanwo.io/ >>> > > > >>> > > >>> > >>> >>
-- Xuanwo https://xuanwo.io/
