Add changes to the release process #19
Conversation
|
The RFC for this is: https://wiki.php.net/rfc/policy-release-process-update |
71e342f to
79facd3
Compare
This is to mostly match the current process and set some rules for it
79facd3 to
5e4a08c
Compare
|
@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? |
|
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 |
|
I did hopefully the last update into this to better clarify backward compatibility section and added also note about the current rules and some recommendation for major version bump. |
|
@iluuu1994 Thanks for checking and adding useful comments. If you could double check whether everything has been addressed, that would be great! |
iluuu1994
left a comment
There was a problem hiding this comment.
Having just looked at the newest commits, they sounds good to me. Thanks for incorporating the feedback!
release-process.rst
Outdated
|
|
||
| - SAPI support is RECOMMENDED to be kept. | ||
|
|
||
| - Internal API compatibility breaks are NOT RECOMMENDED. |
There was a problem hiding this comment.
This does not follow current practice IMHO. We break internal API regularly in minor versions.
There was a problem hiding this comment.
This doesn't prohibit breaking the internal API. It's just NOT RECOMMENDED which is weaker than SHOULD NOT. It means that if there is possibility not to break it (e.g. creating _ex variant function), it's better better not to break it which is what most core devs follow AFAIC to limit the impact on porting extensions. The fact is that we always introduce just couple of breaks in minor versions and we don't do some re-work of the internal API in the minor version so this is just to reflect that. This is different than ABI though.
There was a problem hiding this comment.
But there have been major rewrite of engine APIs in minor versions, the canonical example being when the Zend stream API changed to use zend_strings rather than char* + size_t parameters in 8.1. (see section 1.b of UPGRADING.INTERNALS)
There was a problem hiding this comment.
Ok I changed it so it's:
- Internal API compatibility MAY be broken when necessary (for example,
during refactoring), but SHOULD be preserved whenever possible, such as by
adding an _ex variant of a function instead of changing the existing one.
Does this sound ok to you?
There was a problem hiding this comment.
This does sound better to me, thank you!
| - API compatibility can be broken (internals and userland) | ||
| - ABI can be broken (internals) | ||
| - It SHOULD include bugfixes and new features. | ||
| - Extensions support MAY be ended (moved to PECL). |
There was a problem hiding this comment.
PECL has been deprecated, so we probably should remove this section: (moved to PECL). That's simply a touch up from an earlier RFC (on PECL deprecation), so we can just do that later in a separate commit.
iluuu1994
left a comment
There was a problem hiding this comment.
Can ofc be adjusted after the RFC has been merged.
| - Extensions support can't be removed (like move them to PECL) | ||
| - Backward compatibility must be kept (internals and userland) | ||
| - ABI and API compatibility must be kept (internals) | ||
| - It SHOULD include bug fixes and security patches |
There was a problem hiding this comment.
| - It SHOULD include bug fixes and security patches | |
| - It SHOULD include bug fixes and security patches. |
This is to mostly match the current process and set some rules for it. The will be accompianed by the RFC.