Hi I just read through the releaseprocess RFC( https://wiki.php.net/rfc/releaseprocess ) again, and I think that the part where we explain the Release Process and the BC could be clarified a little bit. (We still haven't agreed on the how many concurrent versions should we support, how long would be a version supported, doing LTS, etc. but thats another topic)
"No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis." I would re-phrase the No feature addition to changing existing behavior, as it now seems a little bit contradictional. "Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6. Binary compatibility can be broken between two features releases, f.e. between 5.3 and 5.4:" it is explained below this line, but maybe it would worth explicitly stating which BC are we referring to, as BC could also mean ABI/Binary compatibility which would again contradict the second sentence. for micro version, I would extend the bugfix part, for example the is_a fix can be called a bugfix, but large amount of code was depending on the buggy behavior hence the change affected a large amount of core out there, and the "right" behavior was achievable through other methods(using additional class_exists/interface_exists), so maybe we could mention some kind of rule for this. "Backward compatibility must be kept (internals and userland)" and "ABI/API compatibility must be kept (internals)" seems overlapping again. I think we should formalize the different kind of BCs, the following were mentioned in the RFC: - moving extensions from core to pecl (maybe also define adding new extensions, or moving from pecl to core) - internal src compatibility - internal ABI compatibility - internal API compatibility - userland API compatibility maybe it would be also a good thing to mention that the preferred way to break userland API compatibility is to first mark the feature/behavior as deprecated (documentation and/or E_DEPRECATED) and only remove it after that (which could only happen with a minor or major version by the RFC) plus the possible migration path should be also documented if possible. what do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
