We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch we'll _also_ have whatever is next, let's call it 5.0.
Nothing is stopping us for discussing CEPs now, and nothing prevents folks from making their own feature branches. If we're going to add another branch (4.0) and let people merge to trunk, we're making an *active* decision to push the 4.0 release out even further, because the folks working on it will have to learn the new code when they merge forward. I'm -1 on branching before we release 4.0. On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <m...@apache.org> wrote: > > > > > Branching anytime before we 4.0.0 adds extra burden to the folks trying > > to > > > get 4.0.0 out the door (because of merge up) > > > > Given both that we've done this with every major release in the past, as > > well as the type of work we'd expect to land during the beta phase > > (smaller, non-api breaking, defect fixing or smaller performance > tuning), I > > didn't personally originally weigh this as being as much of a burden as > you > > perceive it to be. > > > > Looking at this a different way, you might say we have previously cut the > release branch somewhere around beta. Because previous releases haven't > (all) had so much focus on testing and alphas. My impression is that 4.0.0 > will be closer compared to a second or third patch of previous major > releases. > > So I would have thought it makes sense around beta or RC to branch, > especially RC because between RC and GA it is more about a cooling period, > public acceptance and testing. That RC to GA window should be quiet enough > that it makes sense to branch then, and kick off the CEP discussions. > > I don't think the forward merging really is so much of a problem, it's a > normal activity in the C* codebase, and the additional merge-forward window > between either beta or RC, to GA is short. > > Thanks Ekaterina and Benjamin and Josh for raising the discussion. >
