Add changes to the release process #19
Conversation
|
The RFC for this is: https://wiki.php.net/rfc/policy-release-process-update |
bukka
force-pushed
the
release-process-update
branch
from
71e342f to
79facd3
Compare
This is to mostly match the current process and set some rules for it
bukka
force-pushed
the
release-process-update
branch
from
79facd3 to
5e4a08c
Compare
| - Extensions support MAY be ended (moved to PECL). | ||
|
|
||
| - Syntax backward compatibility SHOULD be preserved - every PHP program that | ||
| compiles SHOULD continue to compile. |
There was a problem hiding this comment.
Given this is a SHOULD, I would find it useful to spell out when it is ok to violate this guideline. Namely, any breaking change should go through the RFC process. It should ultimately be up to the community to decide what BC breaks are acceptable. (I see this is later clarified).
There was a problem hiding this comment.
This is already explicitly noted in Feature selection and development section:
However, any change that breaks user-facing backward compatibility MUST go through the RFC process.
| | | <https://wiki.php.net/rfc/release_cycle_update>`_ | | ||
| | | - `RFC: Policy Release Process Update | | ||
| | | <https://wiki.php.net/rfc/policy-release-process-update>`_ | | ||
| +--------------+---------------------------------------------------------------+ |
There was a problem hiding this comment.
Can we not use list-table? changes to formatted tables become very noisy.
There was a problem hiding this comment.
It doesn't seem to allow cell formatting (I need multiple lines for Updates)... But if you can put working nicer format, I'm happy to change it. I spent already quite a bit of time to get it to some acceptable state as it this sort of formatting quite suck in RST.
There was a problem hiding this comment.
I would just have done this:
*Original RFC:* `Request for Comments: Release Process <https://wiki.php.net/rfc/releaseprocess>`_
*Updated By:*
- `RFC: Release Cycle Update <https://wiki.php.net/rfc/release_cycle_update>`_
- `RFC: Policy Release Process Update <https://wiki.php.net/rfc/policy-release-process-update>`_
It doesn't have to be complicated.
There was a problem hiding this comment.
I tried and it looks ugly.
There was a problem hiding this comment.
See https://github.com/php/policies/blob/5a4bdb7a5d518665bf806cdf3f7455025d892ea4/release-process.rst . Basically it looks like it's part of the content.
release-process.rst
Outdated
|
|
||
| - Backwards compatibility breaks in minor versions MUST NOT result in silent | ||
| behavioral differences. Instead any breaking change MUST be "obvious" when | ||
| executing the program. |
There was a problem hiding this comment.
Can you clarify what this looks like in practice? This makes sense when introducing new error cases, i.e. things that now throw an exception. But it doesn't make much sense to change the behavior of non-error cases while then emitting some notice or warning, if the code isn't otherwise considered problematic. If it is problematic, behavior should not change and a deprecation should be emitted instead, so it can later be removed.
There was a problem hiding this comment.
I think the point here is that it should never change for non error cases. For such cases, the deprecation would be used which is not considered as a BC break.
There was a problem hiding this comment.
I noted the error bit there. Let me know if it's ok. Maybe it should be SHOULD?
There was a problem hiding this comment.
@iluuu1994 Given I was the one who suggested this, to give an example: https://wiki.php.net/rfc/static_variable_inheritance would have been an illegal BC break with this policy.
|
@iluuu1994 @TimWolla @jorgsowa @derickr I went through it again today and added notes about SAPI support. Otherwise it looks ready to me unless you have some further points? |
|
|
||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | ||
| "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
| document are to be interpreted as described in `BCP 14 |
There was a problem hiding this comment.
In this document, or in these documents? Not a real problem, but we ought to fix that.
There was a problem hiding this comment.
Sorry, dropped the ball on the mailing list, but unfortunately no one else replied there either. I'm mostly okay with the contents, but feel that the “what are acceptable BC breaks” section could still get some love. Perhaps we should discuss this in foundation Slack to get at least some additional opinions?
| - Syntax backward compatibility SHOULD be preserved - every PHP program that | ||
| compiles SHOULD continue to compile. | ||
|
|
||
| It is critical to understand the consequences of breaking BC, APIs or ABIs (only | ||
| internals related). It should not be done for the sake of doing it. RFCs | ||
| explaining the reasoning behind a breakage and the consequences along with test | ||
| cases and patch(es) should help. | ||
| - Backward compatibility breaks in minor versions MUST NOT result in silent | ||
| behavioral differences. Instead any breaking change MUST be "obvious" when | ||
| executing the program. It means it SHOULD either throw exception or | ||
| trigger error. | ||
|
|
||
| See the following links for explanation about API and ABI: | ||
| - Userland API backward compatibility breaks SHOULD be limited to | ||
| extensions, or the API of functions within an extension. |
There was a problem hiding this comment.
I'd like to see something about “BC breaks must be simple to work-around in a cross-version way”, e.g. what I mentioned in https://externals.io/message/127328#127335.
This is to mostly match the current process and set some rules for it. The will be accompianed by the RFC.