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
