Fwiw, I agree with that POV in general (that it's probably beneficial on balance to branch now/soonish for the reasonings Josh mentioned). -- Sylvain
On Fri, Jun 26, 2020 at 3:43 PM 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 >
