Anyway for 3.0 I think we need to have something new. And I think we could make use of feature branch more, so it will not delay the release. We can focus on the progress of the most important features and make sure they can be done before the release, and for other features, just do not merge them back if they are not ready yet and target to the next major/minor release.
2018-06-05 7:14 GMT+08:00 Josh Elser <els...@apache.org>: > On 6/4/18 12:16 AM, Stack wrote: > >> On Sun, Jun 3, 2018 at 8:54 PM, 张铎(Duo Zhang)<palomino...@gmail.com> >> wrote: >> >> What;s your plan sir? Branch branch-2.1 from branch-2.0? >>> >>> >>> Its a suggestion. >> >> I like Andrew's notion that we left-shift how we have been thinking about >> version numbers; that we releases tend toward minor increments rather than >> patch increments as we have been doing up to this. >> >> If we are going to act on Andrew's suggestion, now is the time to do it. >> >> 2.0.0 was rough. 2.1.0 could be branched from branch-2.0 being 2.0.0 but >> with 100+ bug and perf fixes. I could even see folks deploying a 2.1.0 in >> production. Perhaps there'll be a 2.2.0 and a 2.3.0. They'll be boring bug >> and perf improvements only. >> >> We already have enough to define a substantial 3.0.0 IMO what with serial >> replication and HBASE-20312 CCSMap. >> >> I'm trying to avoid 3.0.0 being like 2.0.0 where it takes years for it to >> ship. Meantime we accumulate a mountain of testing, perf, and whatever >> else >> tech debt. >> >> What do folks think? >> > > mmmm, that's a good point. We keep saying that we aren't going to fall > into the same trap over and over, yet here we are setting ourselves up to > do it again :) > > I would have no complaints against 2.0.0+ becoming 2.1.0, but I feel like > that would make Duo's RM life harder too (assuming branch-2 is more stable > than master). > > I honestly don't know how to balance that. Someone eventually has to bite > the bullet :\ >
