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
