Hi all, Thanks for chiming in with the feedback. Looks like there is broad support for this.
Responding to few of the views below. >With the rush in features without enough tests, I'm afraid the major release version is never ready for production, While I agree with you, don't want to be very idealistic here either. 0.10 for e.g had a lot of testing on RCs and bug fixes after as well. And some of the features were hardened at places at Uber before we released, but open source major releases are generally rough (you can even see how rough newer Spark versions are for e.g), and the community puts in the effort to make it more and more stable going forward. Hudi's problem IMO has been that we have done only major releases from 0.6 to 0.10 (given our resource crunch during the pandemic times). Now, is a good time to revisit this. >when fixing bugs against the master branch, the contributors/committers should also open a new PR We can try this and encourage this always. I am just worried that this adds more burden on contributors and things may get missed. IMO we can pick two RMs at any time. One for the next major release and one for the next minor release and have them shepherd the bug fixes through? We mark JIRAs with two fix versions. >And for minor releases, there should only include the bug fixes, no breaking change, no feature, it should not be a hard work i think. +100 on this. otherwise it defeats the purpose of the minor release. Thanks Vinoth On Wed, Dec 15, 2021 at 7:22 AM leesf <[email protected]> wrote: > +1 > > We could create new branches such as release-0.10 as the master branch for > 0.10.0, 0.10.1 .etc version release, and when fixing bugs against the > master branch, the contributors/committers should also open a new PR > against the release-0.10 branch if needed. That would avoid cherry-picking > all bug fixes from master to release-0.10 at one time and cause so many > conflicts. You would see the Spark[1] and Flink[2] community also > maintaining a multi-master branch as well. > > [1] https://github.com/apache/spark/tree/branch-3.1 > https://github.com/apache/spark/tree/branch-3.2 > [2] https://github.com/apache/flink/tree/release-1.12 > https://github.com/apache/flink/tree/release-1.13 > > vino yang <[email protected]> 于2021年12月15日周三 18:12写道： > > > +1 > > > > Agree that minor release mostly for bug fix purpose. > > > > Best, > > Vino > > > > Danny Chan <[email protected]> 于2021年12月15日周三 10:35写道： > > > > > I guess we must do that for current rapid development and iteration. As > > for > > > the release 0.10.0, after the announcement of only a few days we have > > > received a bunch of bugs reported by the github issues: such as > > > > > > - the empty meta file: https://github.com/apache/hudi/issues/4249 > > > - and the timeline based marker files: > > > https://github.com/apache/hudi/issues/4230 > > > > > > With the rush in features without enough tests, I'm afraid the major > > > release version is never ready for production, unless there is > production > > > validation like in Uber internal. > > > > > > And for minor releases, there should only include the bug fixes, no > > > breaking change, no feature, it should not be a hard work i think. > > > > > > Best, > > > Danny > > > > > > Sivabalan <[email protected]>于2021年12月14日 周二上午4:06写道： > > > > > > > +1 in general. but yeah, not sure if we have resources to do this for > > > every > > > > major release. > > > > > > > > On Mon, Dec 13, 2021 at 10:01 AM Vinoth Chandar <[email protected]> > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > In the past we had plans for minor releases [1], but invariably we > > end > > > up > > > > > doing major ones, which also deliver the bug fixes. > > > > > > > > > > The reason was the cost involved in doing a release. We have made > > some > > > > good > > > > > progress towards regression/integration test, which prompts me to > > > revive > > > > > this. > > > > > > > > > > What does everyone think about a monthly bugfix release on the last > > > > > major/minor version. (not on every major release, we still don't > have > > > > > enough contributors to pull that off IMO). So we would be trying to > > do > > > a > > > > > 0.10.1 early jan for e.g, in this model? > > > > > > > > > > [1] > > > https://cwiki.apache.org/confluence/display/HUDI/Release+Management > > > > > > > > > > Thanks > > > > > Vinoth > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > -Sivabalan > > > > > > > > > >
