Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121664
Return-Path: <derick@php.net>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 43915 invoked from network); 13 Nov 2023 14:30:31 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 13 Nov 2023 14:30:31 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id E0F49180547
	for <internals@lists.php.net>; Mon, 13 Nov 2023 06:30:30 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS,
	SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=3.4.2
X-Spam-ASN: AS30827 82.113.144.0/20
X-Spam-Virus: No
X-Envelope-From: <derick@php.net>
Received: from xdebug.org (xdebug.org [82.113.146.227])
	by php-smtp4.php.net (Postfix) with ESMTP
	for <internals@lists.php.net>; Mon, 13 Nov 2023 06:30:30 -0800 (PST)
Received: from [127.0.0.1] (unknown [148.252.128.122])
	by xdebug.org (Postfix) with ESMTPSA id 4465510C1C7;
	Mon, 13 Nov 2023 14:30:29 +0000 (GMT)
Date: Mon, 13 Nov 2023 14:30:24 +0000
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAEKnhAGShvTi3UPqvw07Kkf2VP8c4YgNJ9Pj9GUR2QbUVhqrag@mail.gmail.com>
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com> <CAPyj-LA278v4mEL3+BmxUUBgk5dW6x=Dssy-4RwWzAe0X4mqqQ@mail.gmail.com> <CAEKnhAGShvTi3UPqvw07Kkf2VP8c4YgNJ9Pj9GUR2QbUVhqrag@mail.gmail.com>
Message-ID: <E87EA966-A2EC-467D-AD18-08F459B16FE4@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Release cycle update
From: derick@php.net (Derick Rethans)

On 10 November 2023 20:22:27 GMT, Jakub Zelenka <bukka@php=2Enet> wrote:
>Hi,
>
>On Fri, Nov 10, 2023 at 5:56=E2=80=AFPM Ilija Tovilo <tovilo=2Eilija@gmai=
l=2Ecom> wrote:
>
>I think there should be a clear cut when the RFC can be implemented and
>there should be probably still time to apply ABI breaking changes after
>that time=2E So we could potentially decrease the time for the RFC
>implementation needs to be merged=2E Maybe something like this:
>
>- 2 alphas - think 2 are enough as each RM can try one release=2E
>- 4 betas and require that all RFC has to be merged before beta3 is
>released=2E It means we would have 2 extra betas to iron out all RFC issu=
es
>and still be able to introduce ABI breaks
>- 4 RC - real feature freeze without any ABI or API breaks
>
>What do you think?



I think that makes sense=2E=20

cheers
Derick