Hello,
I was wondering if it would be useful to add GitHub milestones for the PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones
Because some pull requests might target versions after the PHP-8.4 and it might be useful to have them additionally sorted to not forget about them. Not to tag all PRs of course but only those which are meant to go into some of the future branches.
Thanks.
Hi,
On Wed, Mar 27, 2024 at 3:26 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
Hi Peter
On Wed, Mar 27, 2024 at 9:44 AM Peter Kokot <petk@php.net> wrote:
I was wondering if it would be useful to add GitHub milestones for the PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestonesBecause some pull requests might target versions after the PHP-8.4 and it might be useful to have them additionally sorted to not forget about them. Not to tag all PRs of course but only those which are meant to go into some of the future branches.
Milestones have already been used in the past
(https://github.com/php/php-snilrc/milestones?state=closed), so there’s
no reason not to do the same for 8.4 and 9.0. Most likely, we just
forgot. It’s probably not documented as part of the release process.
We actually decided not to do it for 8.3 because it would be just waste of time to set all PR’s with that milestone. The thing is that PR should just get merged when it’s ready and we won’t be delaying release because some PR’s in that milestone are not ready so it does not have any meaning.
I’m not really sure if there’s any point to have non-draft PR’s targeting next major version because they cannot be merged to master until it is decided the next version will be the major one. So those PR’s should be draft but it might make sense to create milestone for them to show quickly why they are in draft.
So I don’t think there is much point in adding 8.4 milestone but 9.0 might be useful.
Regards
Jakub
Hi Peter
On Wed, Mar 27, 2024 at 9:44 AM Peter Kokot <petk@php.net> wrote:
I was wondering if it would be useful to add GitHub milestones for the PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
Milestones - php/php-src · GitHubBecause some pull requests might target versions after the PHP-8.4 and it might be useful to have them additionally sorted to not forget about them. Not to tag all PRs of course but only those which are meant to go into some of the future branches.
Milestones have already been used in the past
(Milestones - php/php-src · GitHub), so there's
no reason not to do the same for 8.4 and 9.0. Most likely, we just
forgot. It's probably not documented as part of the release process.
RFCs that have actionable tasks for the next major version should be
listed under "Pending Implementation / Landing" on the RFC page:
https://wiki.php.net/rfc#pending_implementationlanding
Adding them to a GitHub Milestone would make it a bit more explicit.
As for PRs that don't have an RFC, adding them to a milestone
definitely makes sense. However, PRs that may only be merged in the
next major version, and _don't_ require an RFC are extremely rare.
Ilija
Hi Jakub
On Wed, Mar 27, 2024 at 4:55 PM Jakub Zelenka <bukka@php.net> wrote:
We actually decided not to do it for 8.3 because it would be just waste of time to set all PR's with that milestone. The thing is that PR should just get merged when it's ready and we won't be delaying release because some PR's in that milestone are not ready so it does not have any meaning.
Thank you, I was unaware that this was a conscious decision. I agree
that it's not particularly useful for the next minor version. If they
are ready, nothing is blocking a merge to master.
I'm not really sure if there's any point to have non-draft PR's targeting next major version because they cannot be merged to master until it is decided the next version will be the major one. So those PR's should be draft but it might make sense to create milestone for them to show quickly why they are in draft.
Draft PRs that target the next major version can make sense if they
are part of an RFC. I generally believe that every RFC should have at
least a proof-of-concept. In my experience, the implementation is the
only reliable way to reveal conceptual issues.
But then again, such RFCs should be in the RFC listing, as mentioned
in my previous message. So I agree that there's not a big need to
milestones.
So I don't think there is much point in adding 8.4 milestone but 9.0 might be useful.
That sounds reasonable to me, as it shouldn't cost much. Milestones
don't need to be complete either, it can be added where it makes
sense, for things that might be forgotten otherwise.
Ilija