Improving Hudi’s Release Cadence #19453
CTTY
started this conversation in
General Discussions
Replies: 2 comments
|
+1 to release more minor releases, and actually that is what we try to do in the past year, it's just the bandwitch, the release takes time. |
0 replies
|
+1 on this. This has been something that we have been trying to push for but we often fall short. Problems i can identify on why we fall short are:
In the past few months, these has changed with the help of LLM assisted reviewed of which committers are leveraging to help get more PRs reviewed, but points (2) and (3) still stand. Just sharing my observations. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Dear Hudi community,
I would like to start a discussion on whether we can make Hudi’s release process faster and more predictable.
I have noticed that recent release roadmaps often include many exciting new features. I am fully supportive of these improvements, but as Hudi continues to grow, bundling more features into each release may increase stabilization time and make releases progressively slower.
One area where release speed is especially important is support for new Spark versions. This is often time-sensitive for users who are upgrading their platforms, and delays can prevent them from adopting newer Spark versions or newer Hudi functionality.
Could we consider being more biased toward releasing Spark compatibility updates quickly, rather than waiting for every planned feature to be completed? More frequent and smaller releases could also allow completed features and fixes to reach users sooner.
The goal would not be to reduce investment in new features, but to avoid coupling every feature to the same release timeline and to make releases easier to stabilize and manage as the project grows.
Would love to hear more perspectives!
All reactions