# little tweeking on the release process RFC - Thread: https://externals.io/message/55740 - Original archive: https://news-web.php.net/php.internals/55740 - Started by Ferenc Kovacs on 2011-10-07T20:28:17+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #55740 — Ferenc Kovacs — 2011-10-07T20:28:17+00:00 URL: https://externals.io/message/55740#55740 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 --- ## #55741 — Ferenc Kovacs — 2011-10-07T20:33:34+00:00 URL: https://externals.io/message/55740#55741 · In reply to: #55740 > - internal src compatibility oh, thats the same as internal API compatibility, then I'm not sure what "src compatibility should be kept if possible, while breakages are allowed" is referring to, as both internals API/ABI, and userland API is mentioned already in the rfc for the minor version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #55745 — Pierre Joye — 2011-10-08T06:27:56+00:00 URL: https://externals.io/message/55740#55745 · In reply to: #55740 > "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 --- ## #55746 — Lester Caine — 2011-10-08T07:55:40+00:00 URL: https://externals.io/message/55740#55746 · In reply to: #55745 Pierre Joye wrote: > > […] > 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. This is where the modular/bundled discussion comes in? Anything that is bundled has to be nailed down, but creating a new extension, or SAPI that is shipped separately is a different matter? Even creating a variation of a currently bundled extension such as a major update to a linked library need not impinge on the core and should not need every other extension to be updated! I'm still of the opinion that there should be more unbundling, then areas like the current debate on MySQL support can be ring fenced to that set of extensions. They are not a core requirement therefore can be left out. ANY changes which bridge the gap between extensions should perhaps be restricted to X.0.0 level anyway. Certainly any bug in an extension which requires the core to be modified to be fixed would indicate a coding problem that needs addressing? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #55747 — Pierre Joye — 2011-10-08T08:02:08+00:00 URL: https://externals.io/message/55740#55747 · In reply to: #55746 > > […] > > This is where the modular/bundled discussion comes in? No, it is not, absolutely not. Please do not hijack again this thread with this discussion, it is totally off topic. SAPIs are what makes possible to get PHP works in a shell, apache, fastcgi, etc. Thanks for your understanding, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55748 — Lester Caine — 2011-10-08T09:38:56+00:00 URL: https://externals.io/message/55740#55748 · In reply to: #55747 Pierre Joye wrote: > > […] > No, it is not, absolutely not. Please do not hijack again this thread > with this discussion, it is totally off topic. > > SAPIs are what makes possible to get PHP works in a shell, apache, fastcgi, etc. > > Thanks for your understanding, Sorry I don't understand why you say this is not the same discussion. Personally I only use an Apache SAPI but I can quite see that other people want a bundle with different SAPI's. These are different targets which a single fully bundled distribution is just excessive. The current pressure is to get even more things included in an already bloated core bundle, when a sensible debate on a more targeted distribution model ... such as like the Linux distributions already break things down to ... makes perfect sense to me. Exactly the same debate is going on with Eclipse distributions, to simplify targeted bundles, and make it easier for people to tailor a bundle to their own requirements ... individual extension/plugins develop with their own version numbers without impinging on the core engine. Self contained modules such as individual SAPI's can be develop independently as required, and should not need to have a debate on whether they should be bundled or not if the distribution model allows their publication as an installation option? Returning to the rfc process ... what still seems to be missing is a way of handling these parallel developments rather than just simply 'throwing them out for pecl to handle'? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #55750 — Pierre Joye — 2011-10-08T11:54:15+00:00 URL: https://externals.io/message/55740#55750 · In reply to: #55748 > Sorry I don't understand why you say this is not the same discussion. > > Personally I only use an Apache SAPI They can't be distributed like pecl's extension. That's why. off topic, take #2. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org