In conclusion, from my perspective maintaining an active release branch with stable patches and major releases every 3 months doesn't provide enough value for the cost
The cost is borne both by me actually creating the releases as well as users who are slowed down picking up updates for dependent libraries (the latest version of tonic, for example). Unless there is significant pushback (ideally along with a volunteer to help maintain a stable branch) I will plan to start doing releases for arrow-rs directly from master as proposed on [1] , starting with arrow-rs 7.0 (will make a candidate later this week and hope to release early next) Thank you, Andrew [1]: https://github.com/apache/arrow-rs/issues/1120 On Tue, Jan 4, 2022 at 4:32 PM Andrew Lamb <al...@influxdata.com> wrote: > > Are there parts of the library that are more stable? > > It is hard to tell -- for example I would have said the "parquet" API is > basically stable (as it hasn't been changed significantly) but there is > some non trivial work afoot to improve its performance which will result in > breaking changes > > > I don't know that the lockstep versioning between Rust and C++ is buying > us anything. > > I agree with this -- I think it is what @Jorge Cardoso Leitão > <jorgecarlei...@gmail.com> predicted during some past discussions related > to arrow2. > > > On Mon, Jan 3, 2022 at 10:18 AM Weston Pace <weston.p...@gmail.com> wrote: > >> Are there parts of the library that are more stable? For example, in >> the C++ API the "parquet" namespace is stable and shouldn't encounter >> much breaking change but the "compute" namespace is marked >> "experimental" (in documentation) and much more liable for breaking >> change. If there were a way to mark particular parts of the API as >> "experimental" then I think these parts could have breaking changes as >> part of a minor release. This obeys the semver rules because your >> experimental APIs are not part of your "public API". >> >> That being said, I'm just backseat driving at this point, so feel free >> to discard the thought. I don't know that the lockstep versioning >> between Rust and C++ is buying us anything. I think it is more >> meaningful for something like R/C++ where the former is just bindings >> upon the latter. There is no guarantee that version X of C++ and >> version X of Rust share any common features or compatibility. >> >> -Weston >> >> On Mon, Jan 3, 2022 at 2:23 AM Andrew Lamb <al...@influxdata.com> wrote: >> > >> > I think Micah and Adam have hit on the core issue -- there are >> inconsistent >> > meanings ascribed to versions numbers "1.0.0" and "stable" >> > >> > Specifically, I think everyone agrees >> > * "1.0.0"+ means "stable" >> > * Some software clearly is unstable (APIs change all the time, couldn't >> be >> > use by other software) >> > * Some software is clearly stable (public API never changes) >> > >> > However, there are many packages that fall between the two extremes >> > (arrow-rs and most of the rust ecosystem in my opinion): that change but >> > are "stable enough" to be used in other projects. >> > >> > I don't really care about the value of the version. What I care about >> are >> > 1. predictable regular releases and >> > 2. allowing the APIs to evolve over time without causing undue stress on >> > users (e.g that their CI jobs start failing without them changing >> anything) >> > >> > Andrew >> >
