Thanks for bringing this up Josh. I think the last time we all discussed this on the mailing list was during the initial freeze thread where we agreed "that between the September freeze date and beta, a new branch would not be created and trunk would only have bug fixes and performance improvements committed to it." Now that we are closer to beta and have a more formal governance model I think its good to revisit.
I'm torn. Folks should absolutely be able to scratch an itch as part of the ethos of the project but we also haven't made substantial progress on the testing epic -- less than I expected when I was +1 to branch at beta in the initial proposal. A few general thoughts come to mind around this: - Does not having a target branch truly discourage folks from scratching an itch? Is the lack of a timeline on when they could actually see that merge in a release more substantial? - Regarding timeline (and scope), I wonder if we would be better branching after we have a bit more of an idea of our future process and development / release lifecycle. Perhaps we should discuss that first? - I haven't seen any CEPs, etc for major features. These discussions aren't blocked by the freeze and would presumably precede any need to merge to trunk? - For smaller changes that don't need CEPs, I know maintaining a long running branch can be a pain but I would like to better understand how many of these are truly out there before asking the committers to maintain and merge into a 4th branch (which is not super challenging but is measurable overhead). Jordan On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jmcken...@apache.org> wrote: > As we close on cutting beta1, a new consequence of our release lifecycle is > becoming apparent. With guarantees of API stability in the beta phase, any > work that is deferred from alpha to the next major due to API impacting > changes will atrophy for as long as the beta is active. > > Cutting a branch for the 4.0 line upon release of beta1 would mitigate this > problem and allow work in flight to be merged in, as well as unblock the > work of others who may not be focusing on testing 4.0, whether it be due to > their interest and focus or due to saturation on the work in scope for the > release. > > The obvious downsides to cutting a branch of a major and allowing dev on > trunk to continue separately is 1) the need to merge up to trunk on changes > going into beta, and 2) a risk of a lack of focus on testing the release > due to the availability of developing on trunk. My personal thoughts on > those two points: > > 1) changes going into beta should be small enough that a fast-forward merge > should be available in the majority of cases up to trunk. We've done this > with previous releases and it wasn't prohibitively expensive in terms of > time. Further, I would posit that changes going into beta should be on the > smaller side, further mitigating the burden of this process. > > 2) We've been feature frozen since late 2018 with the expressed intention > to encourage work on testing and stabilizing 4.0. I am not aware of any > contributors whose time and energy has been invested in testing 4.0 that > would otherwise have gone to trunk (i.e. this approach achieving its > desired outcomes), however I do know of several major contributors and > contributions that have atrophied and been deterred from further work on > the project due to waiting for 4.0 to release. > > I don't think it's appropriate for us as an existing body of contributors > to mandate either how each other or more detrimentally how other new > contributors engage with and contribute to the project by disallowing > contributions past 4.0; I take the position that we should do everything > reasonably possible to encourage a diversity of contributions to the > project. I deeply believe that making deliberate decisions to prioritize > new engagement and interaction on the project as the context in which it's > used evolves is vital to the project's health long term. > > That's just my .02 - I'd be curious to hear what everyone else thinks. > > ~Josh >
