Hi, I would love for us to get into the cadence of a regular bug fix/minor release, on top of the latest major version. What do you think about a minor release every month? Once there is a new major release, we will switch to issuing the next minor release on top of it. i.e once 0.11.0 is out, the next minor will be 0.11.1 and not 0.10.x
On Tue, Dec 28, 2021 at 11:08 AM Sivabalan <n.siv...@gmail.com> wrote: > Following up on having regular minor bug fix release, this is what I am > thinning. > major release every 2 months to 2.5 months and a minor bug fix release on > the following month of major release. If incase major release gets pushed, > we can skip having a 2nd minor release for now(due to resource > availability). > If we have consensus, we can try to have a minor release 1 month after any > major releases. For eg, we had a major release by dec 10. And so jan 2nd > week is when we can target 0.10.1. we might need atleast a month from > major release to have accrued some bug fixes and hence. > > Open to hear thoughts from the community. > > > > On Wed, Dec 15, 2021 at 2:15 PM Vinoth Chandar <vin...@apache.org> wrote: > > > 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 <leesf0...@gmail.com> 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 <yanghua1...@gmail.com> 于2021年12月15日周三 18:12写道： > > > > > > > +1 > > > > > > > > Agree that minor release mostly for bug fix purpose. > > > > > > > > Best, > > > > Vino > > > > > > > > Danny Chan <danny0...@apache.org> 于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 <n.siv...@gmail.com>于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 < > vin...@apache.org > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > -- > Regards, > -Sivabalan >
