Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118804
MIME-Version: 1.0
References: <CAEsg9X0YvRHHKCfFfkR3uYmzwpFps54GvmD7dCcJyXv3nwio-g@mail.gmail.com>
 <a187de08-9488-4407-9255-5bd57ee3daf6@app.fastmail.com> <CAEsg9X2KMAaZnSEqg+36-zZ-p49awoVeuRUnMm4PYJSGYZ--KA@mail.gmail.com>
 <befd2a96-14a3-4b1c-b329-f1dd6f833055@app.fastmail.com>
In-Reply-To: <befd2a96-14a3-4b1c-b329-f1dd6f833055@app.fastmail.com>
Date: Tue, 11 Oct 2022 23:50:50 -0300
Message-ID: <CAEsg9X18LVqhuQn6YB-0oZYhCCKhAZN=LgOML1LqhB1dbxhvjw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009cbc2c05eacd761e"
Subject: Re: [PHP-DEV] Feature preview (formely was: experimental features)
From: david.proweb@gmail.com (David Rodrigues)

--0000000000009cbc2c05eacd761e
Content-Type: text/plain; charset="UTF-8"

From what I understand, your concern is "what if we need to change the
direction of something already decided"? For example, initially it was
decided and very well accepted private(set), but after a while the idea was
revised and it was decided that private:set would be better instead.

In this case, I still believe that the ideal is that this does not change.
But we have a options to decide:

(1) Do not allow changes of this type, as private(set) was initially well
accepted and, unfortunately, nothing can be done. Perhaps, with the
exception of code conflicts that might be discovered later.

(2) Allow BC if the change is reasonable (in this example, if some sort of
code conflict is later discovered). AND:
(2.a) Keep the old syntax (private(set)) at least until the official
version is released, which will use private:set if possible.
(2.b) Keep the old syntax for at least a few releases (eg. patch+3), or a
few months (eg. 6 months) if possible.
(2.c) Consider BC permanent and users will need to change existing codes
immediately.

In particular, I believe that option (1) is ideal, or in the last case
(2.a). While option (2.c) would be easier to maintain and also acceptable,
as users using preview features will be using it at the risk of things like
this happening.

In general, the proposal is to allow new features to be tested more easily
and earlier, as long as they are ready for use and in their final version
(or very close to it). Something like a "Release Candidate" version of this
new feature.



(By top posting, you mean what gmail does by keeping the previous message
at the end of the email, right? I'll be more careful, thanks!)

--0000000000009cbc2c05eacd761e--