On Fri, Oct 7, 2011 at 10:28 PM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> "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. I don't see how it is contradictory. SAPIs are self contained and can't harm another SAPI, that's why we added this clause. > "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. While talking about ABI, it is about internals only, there is no ABI for userland codes. > for micro version, I would extend the bugfix part, for example the > is_a fix can be called a bugfix, It was a bug fix which was causing a BC break and should not have been applied in the 1st place. > "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) That should no't happen in patch releases anymore. > - internal src compatibility > - internal ABI compatibility > - internal API compatibility > - userland API compatibility We added src compatibility for clarity on request. ABI is about internals only, API is about userland and internals. > 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. Not if possible, a must. That's the goal of the migration guide and its version in the PHP manual. The doc team has done a great job so far, let keep it updated, that's the way to go. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
