Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121668
To: internals@lists.php.net
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
Message-ID: <655324D2.1040703@adviesenzo.nl>
Date: Tue, 14 Nov 2023 08:42:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080809040804030706000302"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------080809040804030706000302
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10-11-2023 17:51, Jakub Zelenka wrote:
> Hello,
>
> I would like to propose a new process RFC for updates to PHP release cycle:
>
> https://wiki.php.net/rfc/release_cycle_update
>
> This has been discussed between release managers to make sure that all are
> happy as some of the points impact release managers (e.g. longer security
> support).
>
> I also opened a PR to my new personal repo for RFC's if anyone has got any
> suggestion for better wording or notices any typo:
>
> https://github.com/bukka/php-rfc/pull/1
>

Thank you Jakub for putting this together. A lot of this makes sense to 
me, but the shortening of the feature freeze period from effectively 18 
weeks (with some exceptions) to 8 weeks concerns me.

While this is not a concern for applications in a controlled 
environment, this is a concern for open source projects which don't have 
control over the environment the software is being run on and therefore 
generally "have to be" (try to be) deprecation-free "early", especially 
packages which are used in the CI/QA chain of open source applications 
(think: Composer, PHPUnit, Mockery, Pest etc) and frameworks which are 
widely extended, where the extensions can't really verify their own 
readiness until the framework is deprecation-free (think: WordPress and 
its plugin system).

Taking that into account, I would like suggest the following:
* Yes, 4 RCs, but instead of 2 weeks between each, have 3 weeks between 
each. That way the RC period remains the same, allowing the open source 
world to get ready in time, while still lessening the workload.
* Regarding moving the feature freeze to the first RC: I can see the 
benefits of small features still being allowed in, but deprecations 
going in late is a different matter. While PHP 8.3 was "light" in 
regards to the impact of deprecations, PHP 8.1 and 8.2 were a whole 
different kettle of fish. With that in mind, I'd like to suggest 
deprecations/removals to only be allowed in up to beta 1, with new RFC 
features and other small changes being allowed in until RC1.

I hope you'll consider these suggestions.

Smile,
Juliette


--------------080809040804030706000302--