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
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.
There was a problem hiding this comment.
I changed to SHOULD as it reflects more what we do. It's more a recommendation in that sense.
|
@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? |
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?
release-process.rst
Outdated
| - 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.
There was a problem hiding this comment.
Sorry, I must've missed the notification about this. Will try to take another look tomorrow.
|
Just for the record, I slightly updated the rules for type of fixes in security branches to allow exceptionally merge fixes for some crashes. Let me know if anything about it does not make sense. Specifically it's all in this section: https://github.com/php/policies/blob/97833c8a412fc91b9c4aaa900b57139f6450c2fa/release-process.rst#bug-fix-and-security-releases |
| A backward compatibility (BC) break is defined as any change that prevents | ||
| existing, valid, userland code from continuing to behave as it did in a previous | ||
| version within the same major release. |
There was a problem hiding this comment.
So breaking userland in major versions is not considered a BC break?
I do feel the guidelines in "On Breaking Compatibility" would also apply there?
| A backward compatibility (BC) break is defined as any change that prevents | ||
| existing, valid, userland code from continuing to behave as it did in a previous | ||
| version within the same major release. |
There was a problem hiding this comment.
What does valid mean in this case and in the rest of the document?
Compiling and executing without (fatal) errors?
This is to mostly match the current process and set some rules for it. The will be accompianed by the RFC.