-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSS] More extensive pre-release testing #13661
Comments
BTW I often create WIP PRs to test releases of sqlparser-rs and arow-rs with DataFusion before the release For example: This caught at least one regression before release recently (apache/datafusion-sqlparser-rs#1556, fixed by @goldmedal 🙏 ) |
I agree with the goal, but i am concerned about the cost/overhead involved. We don't have infinite bandwith at disposal.
So what if we focused instead on:
|
Yes, this is true. I imagine an incremental rollout type approach -- where we start with one project (datafusion-python is a natural example, and maybe we can get delta-rs to help too). In my (likely naieve) thinking the downstream projects will be willing to help as they are directly affected |
It is my understanding that the apache voting / approval process prevents automated builds Creating a maintenance branch is also a compelling idea where we can focus on stability / shoring up test coverage 🤔 |
That's my understanding too, but i hope this process isn't nonnegotiable. |
I think as long as we make it clear that nightly builds are not "official" releases from the ASF point of view, we could create / publish them. 🤔 |
That would work for me as long as these releases are the only once we publish. I would want automation for 'the releases' the people use. Especially if we have a maintenance branch, it would reasonable to release after every PR merge. anyway, did we hijack the thread? |
Yeah, we should probably file a separate discussion about more frequent releases if we want to pursue that option |
Is your feature request related to a problem or challenge?
Up to now, when we have made DataFusion releases, we have mostly focused on validated that DataFusion's own unit tests have passed, (see dev/release/README.md) but haven't tested the upgrade with other downstream projects (like ballista, ray, InfluxDB IOx, etc) until after we have release the code
This results sometimes in downstream users finding issues after release. Some recent examples
Invalid comparison operation: Utf8 == Utf8View
error during LEFT ANTI JOIN #13510Describe the solution you'd like
I would like to improve the testing / release process for DataFusion releases to reduce the number of regressions found after release.
This would likely take the form of updating the dev/release/README.md
Describe alternatives you've considered
One idea mentioned by @Omega359 and @andygrove on #13525 (comment)
Additional context
No response
The text was updated successfully, but these errors were encountered: