plewis110 commented on issue #5368: URL: https://github.com/apache/arrow-rs/issues/5368#issuecomment-2093771843
It's probably worth mentioning that making breaking changes and updating the major version of these crates is not that big of a deal to __most__ downstream users if the individual sub-crates are versioned independently. Just compare the number of downloads for [`arrow-array`](https://crates.io/crates/arrow-array) vs [`arrow`](https://crates.io/crates/arrow) on crates.io. --- Breaking changes usually come with improvements and feature additions for the clients of the individual crates; however, when there are no changes to the crates which are being used it becomes extremely problematic because there is no motivation among all dependents to coalesce on the most recent version. This is as @Xuanwo said: > For instance, the library `sun` only uses `parquet v47`. When Arrow releases version 48, the developer reviews the changelog and discovers that only `arrow-array` is affected. Therefore, they can continue using version `>=47` without needing to upgrade. This also has consequences for security updates and vulnerability resolution. If your library clients are conditioned to assume that new versions of their dependencies are not relevant to them, they will be less likely to pull in new security/vulnerability fixes you've pushed to the project. --- Having separate version numbers for all of the sub-crates does not need to be any more of a burden on the maintainers of this crate than the current versioning approach. It should even be less work for maintainers as only a subset of the crates should have version updates due to a single change. Compared to using separate versions for sub-crates, what is the benefit of the current scheme for anyone? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
