ctubbsii commented on PR #3629: URL: https://github.com/apache/accumulo/pull/3629#issuecomment-1654624105
I don't recall any discussion or decision that main is frozen for release. Yes, we've tried not make too many disruptive changes, but we've not agreed to freeze it. I think this isn't really a disruptive change, though... it's a nice cleanup, independent of any other features. Also, if we have stuff for a 3.1, and we know main will become the 3.1 development branch after 3.0.0 is released, we can still open a PR against main, and merge it after 3.0.0 is released from it, if we want it to go into 3.1.0. There are several PRs staged like that already. I think the main reason main hasn't forked a 3.1 branch or 3.0 release-prep branch is because the number of those situations are exceedingly few, and the risk of extra work from merging through an extra branch doesn't make it worth it for so few like that... so it's just easier to leave the few PRs staged. But in this case, it probably could have been included in 3.0 rather than left staged and deferred to 3.1. My main concern, though, is that I don't want our community to be fractured by people starting to treat the elasticity branch as the primary development branch, while others are still focused on the mostly independent work in main. The primary development branch, as its name implies, should still be `main`, while the `elasticity` branch is still the experimental branch focused on developing elastic features. In order to support the often-discussed community goals of more frequent releases and more intermediate milestone releases (such as non-LTM ones), we need to keep features independent from one another. Too tightly coupling one feature that could be independent with another large long-running feature, instead of doing these incremental changes on the primary development branch, increases the risks of creating a situation like what we had for 2.0 and 2.1, where we had very long-running (multi-year) development cycles, or situations like what happened prior to that, where some su rprising changes went overlooked because they occurred in a feature branch that got merged quickly, and ended up causing problems later (for example: all the internal API leaks that required us revisiting and churning all the affected APIs). So, for features that aren't directly elasticity-related, I don't think they should target the elasticity branch... they should target the primary development branch, if they can. This helps incorporate these changes sooner, and also helps the elasticity branch be smaller, and easier to incorporate later. For this one, it can probably be easily backported... or omitted from 3.x entirely... but I'm more concerned about the larger principle of encouraging the use of `main` as the primary development branch, off of which other feature branches are based, to make sure we're still all on the same page, so we can continue to make incremental progress on multiple fronts. I would prefer we not tightly couple features together that don't need to be, as that makes incremental progress harder and take longer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
