Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120312 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84809 invoked from network); 16 May 2023 12:39:46 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 May 2023 12:39:46 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6E1671804F8 for ; Tue, 16 May 2023 05:39:42 -0700 (PDT) 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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 May 2023 05:39:42 -0700 (PDT) Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-96598a7c5e0so2282439466b.3 for ; Tue, 16 May 2023 05:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20221208.gappssmtp.com; s=20221208; t=1684240781; x=1686832781; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hn+STYm5zFbfjYjGPnXH925E+bCjhBVntX2fm/lk128=; b=UVqMNKgs2Xt360gHcoVFcE84jJgwzB7YZgSFIz7IaSloZ/rqP3Fr4pCmnGzq2Jw67I xWrlfE3VKRQgSAcoqjIDAsOX79QuObt6GTE2hkepZKjadfLd+QmqvhXZFMS4io5xocWM 6qksq0Ag8+30Oek5cw2ZnyIGhCJK71Xge6xrTsbxwUkFwJCcvXaIq+Ue+0QlLXtKamFg DB8rR9S8zqstMzYQQWB8el4VmWKn3j/HtWWyLb27mQpQNrzxy58Vy+Q5JP2d4S7bC0mG W6Ifl8o1R1th0svE/9TROSm54Y/naZKXhVFv1ukNuqwXdM6GqGKmonqvRxhXGo2lPIO/ nfHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684240781; x=1686832781; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hn+STYm5zFbfjYjGPnXH925E+bCjhBVntX2fm/lk128=; b=fJY3kHit//a2nW1Lml+M8p7ECc9Pl9aZ5mjFNSl0o8zOWXVz5X9WUB0JFz53mRj4sB Vdns75bMHeAyL1z9zDJfW41dnNs+vpYuCTSvyxeZOnDNK1XA3UBtx8lIgHa308pcikBp jrNsoZXMQiCdSelyB2uc+sPJVzvOdj2h/bXyHH6K1jFI/b3K9c7vWD4k1C8snpR3t49B 0Q/wJmUDN4gGcyM5giZf0sQlETSOg3eUdqY4uwC5K0ZXMK4eje6LiZwuTd5CG5GG9jKp 0eeqAOFDz7Z9XnRkpWolqNzHA2aBmDUPZXZv1cudTZhua9aLnfN8IhFfOswFU0QD67lz KTDQ== X-Gm-Message-State: AC+VfDwy4GYrf8ZpwZh6VMAyn/m2qPgiZcPY/0sRsSn/h0RFaMBkent6 WEOPXEBeDqssOx5cnevVLzlNs5+gTm487AdWN5gLgKbUjNF8GQuK/XFDmw== X-Google-Smtp-Source: ACHHUZ6iIXLR2IWY1BTOjbRsRD2I5aYwqFpvUeXhjxJ+Jz6kxuDclPopjSEsX0nymp+Gn2jZmJgrB/WTFxX+n/YA8vE= X-Received: by 2002:a17:907:31c7:b0:965:d18b:f03a with SMTP id xf7-20020a17090731c700b00965d18bf03amr32108960ejb.58.1684240780736; Tue, 16 May 2023 05:39:40 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 16 May 2023 13:39:30 +0100 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Planning ahead, will 8.5 exist and major version decisions (was: Deprecate functions with overloaded signatures) From: Danack@basereality.com (Dan Ackroyd) On Sat, 13 May 2023 at 00:08, Larry Garfield wrote: > > I am actually tempted to propose that we do deprecations at the very > start of a release, 9.0 and 9.1 only, and then not allow them for the > rest of that major, for that exact reason. That sounds really unwise. People aren't that enthusiastic about volunteering to work on things that would take 5 years to deliver a change. It would make maintaining PHP be a lot harder, and also be a burden on core maintainers. On Mon, 15 May 2023 at 09:55, G. P. B. wrote: > > Why are we assuming that PHP 9.0 is going to come after PHP 8.4? Partly because I experience time linearly? And afaik, no-one has a lot of negative emotional feelings about the number 9. But I guess maybe you meant, "why are people assuming PHP 8.5 won't exist?". On Mon, 15 May 2023 at 19:39, Larry Garfield wrote: > > Tangent: If I were to put together an RFC that set out such a 5 year cycle > expectation with reasonable guidelines around when things could be deprecated, > would anyone actually support it? I think that would cause more drama. IMHO, you seem more attracted to having processes and schedules written down, than core devs appear to.[1] Although we should probably discuss when major releases happen, we should start that conversation off by asking questions. I've only been taking part in internals discussions for two major releases, and it's pretty unclear to me how the decision to stop releasing on the 5.x and 7.x branches was made. I would appreciate any core contributors[2] thoughts on any of the following: * Are there any things being worked on that would deserve or require a major version bump in PHP? * In particular, should we expect PHP 8.5 to be a thing, or should we expect PHP 8.4 to be the last release of the PHP 8.x branch? * Is there, or could there be, a process for planning when the next major release is going to happen? Or would requiring volunteers to plan their volunteering multiple years in advance be too much of a burden? cheers Dan Ack [1] I agree with the people who actually do the maintenance here. Fixed processes don't actually help that much on a project the size of PHP. Most of the time people are sensible and can be reasonable about things, even if their priorities aren't the same as other people, and so to outsiders they don't appear as reasonable. [2] I am sure lots of userland people and other people will have opinions also. I just don't think they will be as insightful or useful in this conversation.