I think that this goes well with the philosophy of the open source and volunteering contributions. Also, it could really open the door for more new features and people contributing to the project in the long term. Ekaterina
On Fri, 26 Jun 2020 at 10:44, Sylvain Lebresne <lebre...@gmail.com> wrote: > 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 > > >
