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