tustvold commented on issue #5368: URL: https://github.com/apache/arrow-rs/issues/5368#issuecomment-2079119343
> I would agree: if ASF release process is fine with arrow-rs having separate releases, it should not have a problem with each crate having its own versioning. My understanding is we would then need to hold separate votes and run separate release processes for each individual crate, I am not sure this is practical. > It looks like this is still the case, but not because of change to the arrow or the core crates, but because dependencies to pyo3 and object_storage, which are still "fast moving". I think this is over-fitting to the exact current circumstance, the reality **is arrow-rs is not a `1.x.x` crate**, it exposes `0.x.x` crates in its public APIs, and we frequently make breaking changes to the core array definitions. For example, adding new view array types, altering UnionArray constructors, or fixing the definition of intervals. The only reason arrow is not `0.x.x` is a historical artifact of when it was tied into the broader arrow releases. Whilst I accept that making breaking releases is painful, the reality is arrow-rs, its dependencies, and the arrow specification in general **are not yet mature enough to commit to a long-term stable API**. Whilst I appreciate all the engagement with this issue, I don't think it is practical to pretend we are at a level of maturity that we are not. To do so would be to risk the ossification that afflicts the parquet ecosystem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
