On Tue, Dec 13, 2022 at 12:03 PM Tim Düsterhus <t...@bastelstu.be> wrote: > One benefit of removing those branches would be, that usability of > GitHub's branch selector improves, specifically the branch selector when > creating a new PR. >
Maybe this is my CLI privilege talking, but who's using pulldowns to select PR branches? Sepcifically, IME we tend to get PRs against the `master` branch. All that aside, I do agree that the dropdown's contents can be daunting. It's a big list. But: 1/ We're unlikely to get rid of the release branches 100%. The current RC cycles have branches for their release so that we can add revisions onto the RC and get a stable final. So at minimum, there's going to be a release branch in place for each active release on 16 out of 28 days (slightly more than 50% of the time). Sure, that's just a couple of version specific branches instead of hundreds, and that point is well taken, but my counterpoint is that we will have working branches. 2/ I'm not convinced this is a confusing scheme. While php-src doesn't follow perfect semver, we certainly have something recognizable to the broader OSS development community, and if you see PHP-8.0 PHP-8.0.0 PHP-8.0.1 etc... I think a programmer is going to being able to sus out the meaning of these branches. Even if they don't, the review process will easily be able to set them straight. TL;DR We can expect a reasonable amount of sense on the part of anyone who has any reason to be poking around branches. Given #2, I don't see a significant benefit, given #1 I see that benefit being naturally mitigated, and I don't see removing data from our repo as being valuable. Just my personal feeling on the matter, don't let me discourage you from bringing this to an RFC and holding a vote. -Sara
