Re: Remove PHP-x.y.* git branches
| From: | Sara Golemon | Date: | Wed, 14 Dec 2022 20:04:18 +0000 |
| Subject: | Re: Remove PHP-x.y.* git branches | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119144@lists.php.net to get a copy of this message | ||
On Tue, Dec 13, 2022 at 12:03 PM Tim Düsterhus <tim@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