While I don't know how much legacy API support would downstream projects need (without a good case Andrews suggestion should be the "default", keeping minor / patch versions is the extra workflow), there is one nit I can add: According to the Rust recommendations every package used as a dependency for other packages should have 1.0+ version and use semantic versioning (exactly what Andrew proposed) https://semver.org/#how-do-i-know-when-to-release-100
The proposed behavior could lead to a toxic and messy arrow-rs package, however if someone feels this is happening, we should maintain smaller packages (arrow-rs broken into multiple crates), not changing whether we follow semver or how we bend the guidance. Best regards, Adam Lippai On Sun, Jan 2, 2022 at 2:52 PM Micah Kornfield <emkornfi...@gmail.com> wrote: > Hi Andrew, > Happy new year. I'm not familiar with Rust but it seems like a lot of the > intention here is to really treat Arrow-RS as a pre-1.0 package (we should > maybe be doing the same for other libraries as well but that is a separate > issue). Is it possible to deprecate the existing arrow-rs and create a new > 'arrow-rs2' package and keep it at a pre-1.0 until the community feels that > it has reached 1.0. > > I'm sure this will cause some pain and confusion but it might be better in > the long run? > > -Micah > > On Sat, Jan 1, 2022 at 4:55 AM Andrew Lamb <al...@influxdata.com> wrote: > > > Happy New Year, > > > > I would like to discuss more frequent major arrow-rs releases and have > > written my thoughts on a ticket [1] and would love any additional > community > > feedback. Among other things this would result in versions that no longer > > align with the C/C++ implementation. > > > > Thanks, > > Andrew > > > > [1]: https://github.com/apache/arrow-rs/issues/1120 > > >
