alamb commented on issue #13525: URL: https://github.com/apache/datafusion/issues/13525#issuecomment-2499064530
> It's not really captured by semver, but it would be nice if there were a distinction between breaking changes that simply require fixing compilation errors in a straightforward way, vs those that are changes in behavior without API changes. I think this is an astute observation: Figuring out how to flag PRs that make changes that are not "breaking" in the API sense but are breaking in some semantic sense. > I would suggest that we file tickets as part of every release to test DF with latest versions of common external dependencies (datafusion-python, iceberg, lance, delta, etc) as part of the gating criteria for a release. Perhaps this would be as simple as changing the DF version in those projects and running their test suite. Any blockers that are found in DF have tickets filed and are fixed, other blockers in the respective projects have tickets filed in those projects I think this would be a great idea, and I often try to do exactly this (as a sanity check) with `arrow-rs` releases or sqlparser-rs releases (e.g. [here](https://github.com/apache/datafusion/pull/13546)) before I release them to crates.io > Upgrading our own subprojects (Ballista, Comet, DF Python, DF Ray) as part of the DataFusion release process makes a lot of sense to validate that the upgrade guide is complete. Maybe just doing this -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
