# Final version, RFC release process - Thread: https://externals.io/message/52647 - Original archive: https://news-web.php.net/php.internals/52647 - Started by Pierre Joye on 2011-06-01T10:09:26+00:00 - Messages: 38 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/52647.md?page=2 - 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 --- ## #52647 — Pierre Joye — 2011-06-01T10:09:26+00:00 URL: https://externals.io/message/52647#52647 Hi, Long due but finally sending the final RFC for the release process. There a couple of changes since the last time, they are all about making it more transparent or catch the edge cases. We also got new proposers on board, we are now basically almost all active devs on board. URL: https://wiki.php.net/rfc/releaseprocess In parallel to the current discussions about 5.4's features, let get this RFC approved and use right away for 5.3 (to define its life time) and 5.4. That will spare us the issues we had in the past with 5.3, for example and ensure that we get 5.4 release in a reasonable timeframe and without endless delays, or features additions. It is important to keep in mind that this RFC is not written in stone but it is a good base to begin with. We can always adapt it later, if necessary. https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add your svn id. Proposers do not need to do it as they are indeed there as +1 already (I added myself as example) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52649 — Dmitry Stogov — 2011-06-01T11:07:35+00:00 URL: https://externals.io/message/52647#52649 · In reply to: #52647 Hi, In my opinion a restriction "API compatibility must be kept (internals and userland)" for x.y.z to x.y+1.z is too strict. It just can block some new features forever. I would suggest to change "API compatibility must be kept" to "API backward compatibility must be kept as much as possible". Thanks. Dmitry. > Hi, > > Long due but finally sending the final RFC for the release process. > > There a couple of changes since the last time, they are all about > making it more transparent or catch the edge cases. We also got new > proposers on board, we are now basically almost all active devs on > board. > > URL: https://wiki.php.net/rfc/releaseprocess > > In parallel to the current discussions about 5.4's features, let get > this RFC approved and use right away for 5.3 (to define its life time) > and 5.4. That will spare us the issues we had in the past with 5.3, > for example and ensure that we get 5.4 release in a reasonable > timeframe and without endless delays, or features additions. > > It is important to keep in mind that this RFC is not written in stone > but it is a good base to begin with. We can always adapt it later, if > necessary. > > https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add > your svn id. Proposers do not need to do it as they are indeed there > as +1 already (I added myself as example) > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52650 — Pierre Joye — 2011-06-01T11:12:00+00:00 URL: https://externals.io/message/52647#52650 · In reply to: #52649 hi, > Hi, > > In my opinion a restriction "API compatibility must be kept (internals and > userland)" for x.y.z to x.y+1.z is too strict. It just can block some new > features forever. btw, new APIs do not break API or API. I do not think we should allow BC breaks between x.y and x.y+1. That's counter productive and prevent users to migrate easily and quicker. That's the whole point of having more frequent releases. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52651 — Pierre Joye — 2011-06-01T11:15:05+00:00 URL: https://externals.io/message/52647#52651 · In reply to: #52650 > hi, > > > > […] > > btw, new APIs do not break API or API. I mean API or ABI. > I do not think we should allow BC breaks between x.y and x.y+1. That's > counter productive and prevent users to migrate easily and quicker. > That's the whole point of having more frequent releases. We could allow BC break internally, using your wording, but that's something I do not like either. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52652 — John Crenshaw — 2011-06-01T11:19:22+00:00 URL: https://externals.io/message/52647#52652 · In reply to: #52649 That isn't measurable, so it is a suggestion, not a standard. It also creates serious problems in userland if APIs change. API changes lead hosts to literally take years to update to new versions of PHP, for fear of breaking the sites that host with them. What about: Userland API compatibility of documented interfaces and behaviors must be kept. API internals should be backwards compatible wherever possible. This relaxes the userland restriction just slightly to allow for changes that break undocumented behaviors, but leaves it basically stable and measurable. This also leaves the door open for internal changes if they're really needed, but basically suggests against it. John Crenshaw Priacta, Inc. -----Original Message----- From: Dmitry Stogov [mailto:dmitry@zend.com] Sent: Wednesday, June 01, 2011 7:08 AM To: Pierre Joye Cc: PHP internals Subject: Re: [PHP-DEV] Final version, RFC release process Hi, In my opinion a restriction "API compatibility must be kept (internals and userland)" for x.y.z to x.y+1.z is too strict. It just can block some new features forever. I would suggest to change "API compatibility must be kept" to "API backward compatibility must be kept as much as possible". Thanks. Dmitry. --- ## #52653 — Derick Rethans — 2011-06-01T11:31:38+00:00 URL: https://externals.io/message/52647#52653 · In reply to: #52647 > URL: https://wiki.php.net/rfc/releaseprocess Comments again-they are mostly similar as before-I was quite annoyed that I didn't even get feedback on when I sent it last time: > ==== Example time line with two majors versions ==== > However it could happen that a new major version is desired while the > active major version is still heavily used. Like what we had between > php 4 and 5 or for the oldest, between php 3 and 4. Because of this, Perhaps the latest release before a new major one should run for a year longer. So in the example above, 5.6 runs until where 6.0 ends too. > > **** pre release phase > ++++ release lifetime bugs > ---- release lifetime security only > D EOL > Version Time -> > 2011 2012 2013 2014 2015 2016 2017 > | | | | | | | | | | | | | > 5.3 +++++++++++++-----D > 5.4 |*****+++++++++++++++++++++++++-----------D | | | | | > 5.5 | | |******++++++++++++++++++++++++-----------D | | | > 5.6 | | | |******++++++++++++++++++++++++-----------D > 6.0 | | |******++++++++++++++++++++++++-----------D | | > 6.1 | | | |******++++++++++++++++++++++++-----------D > This variant is not workable, because there are (in the example) in 2014 *five* branches. Merging between those, manually and automatically is going to be a major pain. I'd say we all rather want to focus our time on fixes and new features; and not spend more time doing branch merging, whatever tool we use for this. I prefer the other one that was suggested before: > ==== Example time line with only one major version at a time ==== > > **** pre release phase > ++++ release lifetime with all bugs fixes, no feature addition > ---- release lifetime security fixes only > D EOL > Version Time -> > 2011 2012 2013 2014 2015 2016 2017 > | | | | | | | | | | | | | > 5.3 +++++++++++++-----D > 5.4 |*****+++++++++++++++++++++++++-----------D > 5.5 | | |******++++++++++++++++++++++++-----------D > 5.6 | | | | |******++++++++++++++++++++++++-----------D > 6.0 | | | | |******++++++++++++++++++++++++-----------D > 6.1 | | | | |******++++++++++++++++++++++++-----------D > > ==== Timeline example for a release ==== > > > * June > * Decisions which features or changes will be in the next release > * 1st release alpha (may have many alpha) > * At least one release per month, more at wish > * Septempber, RC phases, biweekly release > * each RC should go through the QA before being published > * usually2 days Uh? The whole RC phase is QA. I don't see why you need another QA 'period'. I would however want to say that packaging and bundling is done on Wednesday, with any release on Thursday (morning). The original idea was to not have just a Friday for people to upgrade before a weekend. I've always bundled/packages on Wednesday and released on Thursday, but I've seen that lately it's all done on Thursday, and sometimes even Thursday evening US time. > * running the various test suites (phpt, custom real life tests, > platform specific tests). Some tests need a day to run > * November, Final > * Last RC taken as final, golden release (no change between the last RC and the final version) TBH, I think 6 months is too much between first alpha and release. Because we'd only have 6 months for a "normal cycle". > ===== Feature selection and development ===== > > RFCs have been introduced two years ago and have been proven as being > an amazing way to avoid conflicts while providing a very good way to > propose new things to php.net. New features or additions to the core > should go through the RFC process. New big language features, I agree with. Small little self-contained extension functions do not need a full blown RFC process. Extension's maintainers should have the responsibilty for this. (I am not saying it wouldn't be good to have an RFC for some of those new additions though). > It has been done successfully (as > the process went well, but the features were not necessary accepted) > already for a dozen of new features or improvements. One issue with it though, the page that lists all the RFCs isn't maintained, and status isn't always updated. That needs to be done otherwise we get to "oh, is this implemented yet?" > Features can use branch(es) if necessary, doing so will minimize the > impact of other commits and changes on the development of a specific > feature (or the other way 'round). The shorter release cycle also > ensures that a given feature can get into the next release, as long as > the RFC has been accepted. I would word "can use branches if necessary" stronger, like "can use branches if *absolutely* necessary". The reason why, is that it is a good idea to get as many people familiar with new code. Of course, if there is a lot of ongoing work then a feature branch helps, but it should be merged into trunk as soon as it compiles (and doesn't break any test case) for peer review and more testing. > The change to what we have now is the voting process. It will not > happen anymore on the mailing list but in the RFCs directly, for > php.net members, in an anonymous way (who votes what won't be made > public). > > The question for this section is about who will be allowed to vote: > * php-src (yes, no) > * php-doc (yes, no) > * qa, *phpt (yes, no) > * other sub projects like pear (yes, no) > > NB: the poll plugin will be installed shortly A few things here that I don't like. First of all, I think voting *should* be public. I've nothing to hide, and I hope nobody else has either. Voting just on a wiki is too hidden as well- I think it should happen on the mailinglist with just +1, 0 and -1 responses. I quite like the Apache model: http://www.apache.org/foundation/voting.html and wouldn't mind adopting that in a slightly modified way. It is important however that votes come without comments. > ===== Feature(s) preview release, solving the experimental features ===== > > Some features require a lot of testing or users feedback before they > can be considered as ready, stable enough or proven as having made > good design decisions. Having them in normal releases is dangerous. > The past releases told us more that once than many good ideas ended as > being not so good after all. But we had to keep them in and, even > worst, maintain them forever. > > A feature preview release could solve this problem. A feature(s) > preview release gives us and our users a way to try bleeding edge > additions to the language or core while providing us with an > invaluable feedback to actually valid both the implementation and the > design choices. > Non core features (engine, stream, etc.) could benefit from a feature > preview release while doing it via PECL should be the preferred way. > > Feature(s) preview releases can happen any time and can be platform > specific. Whether a specific development branch is used or not is up > to the developers of the given features (external repositories like > github or bitbucket can obviously be used as well). Isn't a feature preview just a snapshot or (the first) alpha? I don't want to see various feature releases that don't have just trunk. The reason being mostly is that we would want to avoid splintering of "what is PHP"? Even more, because if we say "feature release" people might actually start using that to write applications against. I also don't see with being platform specific has to do with this. PHP is PHP, and on each platform PHP is (or at least should be) behaving the same. That also brings me to the point that all our downloads should be in one place: http://snaps.php.net for snapshots, and http://php.net/releases/index.php for releases. It makes no sense to have them spread over multiple locations. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #52656 — Ilia Alshanetsky — 2011-06-01T11:45:29+00:00 URL: https://externals.io/message/52647#52656 · In reply to: #52653 > This variant is not workable, because there are (in the example) in 2014 > *five* branches. Merging between those, manually and automatically is > going to be a major pain. I'd say we all rather want to focus our time > on fixes and new features; and not spend more time doing branch merging, > whatever tool we use for this. This is similar to my initial point about the proposal. We need to figure out a way to have fewer active bug-fix branches, just because it make dev live very difficult. Derick I am not sure your example is much better, since you still have 4 active branches (if I am reading the diagram correctly). I think 3 active bug fix branches, with maybe 1 security fixes only branches is the most we should have. --- ## #52657 — Pierre Joye — 2011-06-01T11:48:36+00:00 URL: https://externals.io/message/52647#52657 · In reply to: #52656 > > […] > > This is similar to my initial point about the proposal. We need to > figure out a way to have fewer active bug-fix branches, just because > it make dev live very difficult. Derick I am not sure your example is > much better, since you still have 4 active branches (if I am reading > the diagram correctly). I think 3 active bug fix branches, with maybe > 1 security fixes only branches is the most we should have. yes, and we can adapt that in time and when necessary. The core of this RFC however is still valid and is a very good step forward for our project (that's for Derick's reply). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52660 — Pierre Joye — 2011-06-01T11:55:11+00:00 URL: https://externals.io/message/52647#52660 · In reply to: #52653 > > […] > > TBH, I think 6 months is too much between first alpha and release. > Because we'd only have 6 months for a "normal cycle". That's a max and reasonable time frame based on what we had in the past and based on discussions with the devs actually doing the work. So what if we make it before? a wonder! But at least there is a max deadline. > One issue with it though, the page that lists all the RFCs isn't > maintained, and status isn't always updated. That needs to be done > otherwise  we get to "oh, is this implemented yet?" help welcomes. > > […] > > I would word "can use branches if necessary" stronger, like "can use > branches if *absolutely* necessary". The reason why, is that it is a good > idea to get as many people familiar with new code. Of course, if there > is a lot of ongoing work then a feature branch helps, but it should be > merged into trunk as soon as it compiles (and doesn't break any test > case) for peer review and more testing. do not see a reason to change this part, it is self explaining and if a developer likes to use an extra branche, then it is up to him as he maintains that code anyway, at least for the development period. > > […] > > A few things here that I don't like. First of all, I think voting > *should* be public. Please read the RFC. > > […] > Isn't a feature preview just a snapshot or (the first) alpha? no, and it may not be ready in time for a given release. And that allows us to show something at any time to get more feedbacks from users about a given complex or big feature/change without taking the risk to break a given normal release. That sounds like a good solution and can be done at any time. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52669 — johannes@schlueters.de — 2011-06-01T12:44:23+00:00 URL: https://externals.io/message/52647#52669 · In reply to: #52656 > > […] > > This is similar to my initial point about the proposal. We need to > figure out a way to have fewer active bug-fix branches, just because > it make dev live very difficult. Derick I am not sure your example is > much better, since you still have 4 active branches (if I am reading > the diagram correctly). I think 3 active bug fix branches, with maybe > 1 security fixes only branches is the most we should have. I mentioned this before: I like the Ubuntu model: * One development branch for the next version * One current version * One "long term" supported version The current version is aimed to give early access to new features, to avoid cases like traits which take years to come out while a bit more conservative users (and maybe distros) may stay on the LTS. Once a new "current" comes out there won't be fixes for the previous anymore. Every n-th "current" release will be a long term supported (LTS) release receiving only only only bug fixing and the older it gets the more critical bugs, only. What "long term" means can be discussed. It is open for discussion if a LTS version will directly terminate the previous LTS version or whether an LTS version will be released instead of an "current" version, so for one period there would be two LTS but no "current" branch. johannes --- ## #52670 — Ilia Alshanetsky — 2011-06-01T12:50:08+00:00 URL: https://externals.io/message/52647#52670 · In reply to: #52669 Sounds reasonable. 2011/6/1 Johannes Schlüter : > > > […] > > I mentioned this before: I like the Ubuntu model: > > * One development branch for the next version > * One current version > * One "long term" supported version > > The current version is aimed to give early access to new features, to > avoid cases like traits which take years to come out while a bit more > conservative users (and maybe distros) may stay on the LTS. Once a new > "current" comes out there won't be fixes for the previous anymore. > Every n-th "current" release will be a long term supported (LTS) release > receiving only only only bug fixing and the older it gets the more > critical bugs, only. What "long term" means can be discussed. > It is open for discussion if a LTS version will directly terminate the > previous LTS version or whether an LTS version will be released instead > of an "current" version, so for one period there would be two LTS but no > "current" branch. > > johannes --- ## #52673 — Pierre Joye — 2011-06-01T13:44:54+00:00 URL: https://externals.io/message/52647#52673 · In reply to: #52669 hi, 2011/6/1 Johannes Schlüter : > > > […] > > I mentioned this before: I like the Ubuntu model: > * One development branch for the next version > * One current version > * One "long term" supported version I do not like it. It does not apply to a programming language and its requirement from an end user point of view. To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a drastic improvement for ISPs, framework developers etc. The issue about having multiple or too many branches active is a non problem imo. Yes, it takes a couple of hours yet to release php, but that's something that could be automated easily (the tasks, not the whole thing) . It will also be much safer to do it given that no fancy commits can or should be applied in patch releases/stable branches. In addition we are getting more and more automated testing and that will make the release processes even smoother and safer. Unlike now where we need months to do 5.3 patches when we should have at least .7 already and .8 being in the work. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52674 — Ilia Alshanetsky — 2011-06-01T13:55:30+00:00 URL: https://externals.io/message/52647#52674 · In reply to: #52673 Pierre, Doing a release could be simplified through automation as you've said. However keeping synchronized patches across frequently incompatible (non-identical) code bases is much less trivial and requires quite a bit of work by anyone making the bug fixes. Having >3 branches for bug fixes makes this very non-trivial and time consuming, which is why Johannes' proposal is so appealing. 2011/6/1 Pierre Joye : > hi, > > > 2011/6/1 Johannes Schlüter : > > […] > > > […] > > I do not like it. It does not apply to a programming language and its > requirement from an end user point of view. > > To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a > drastic improvement for ISPs, framework developers etc. > > The issue about having multiple or too many branches active is a non > problem imo. Yes, it takes a couple of hours yet to release php, but > that's something that could be automated easily (the tasks, not the > whole thing) . It will also be much safer to do it given that no fancy > commits can or should be applied in patch releases/stable branches. > > In addition we are getting more and more automated testing and that > will make the release processes even smoother and safer. Unlike now > where we need months to do 5.3 patches when we should have at least .7 > already and .8 being in the work. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52675 — Pierre Joye — 2011-06-01T13:59:21+00:00 URL: https://externals.io/message/52647#52675 · In reply to: #52674 2011/6/1 Ilia Alshanetsky : > Pierre, > > Doing a release could be simplified through automation as you've said. > However keeping synchronized patches across frequently incompatible > (non-identical) code bases is much less trivial and requires quite a > bit of work by anyone making the bug fixes. Having >3 branches for bug > fixes makes this very non-trivial and time consuming, which is why > Johannes' proposal is so appealing. I don't think we will ever have >3 releases for bug fixes but maybe 3-4 max with 2-3 in security modes. In this case it is really easy to maintain and release. Random LTS at random point with random life time for releases is not something I want for PHP. It is basically what we have now and PHP users are really not happy about that (and many devs). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52677 — Benjamin Dubois — 2011-06-01T14:26:03+00:00 URL: https://externals.io/message/52647#52677 · In reply to: #52647 Hi, From a userland perspective, there should be absolutely no feature addition in a "bugfix" version (x.y.Z+1) : we would see (just like what we see today) frameworks, apps, or libraries depending on specific bugfix releases, and this would not make php versioning easier to understand for anybody. And for you core devs, this is an open window for bypassing the standard versioning process, which could result in long discussions or determining if a feature is a self-containing one or not, and should be released in a bugfix version. Allowing these exceptions would not IMO enhance the release process... Cheers -- Benjamin Dubois Le mercredi 1 juin 2011 à 12:09, Pierre Joye a écrit : > Hi, > > Long due but finally sending the final RFC for the release process. > > There a couple of changes since the last time, they are all about > making it more transparent or catch the edge cases. We also got new > proposers on board, we are now basically almost all active devs on > board. > > URL: https://wiki.php.net/rfc/releaseprocess > > In parallel to the current discussions about 5.4's features, let get > this RFC approved and use right away for 5.3 (to define its life time) > and 5.4. That will spare us the issues we had in the past with 5.3, > for example and ensure that we get 5.4 release in a reasonable > timeframe and without endless delays, or features additions. > > It is important to keep in mind that this RFC is not written in stone > but it is a good base to begin with. We can always adapt it later, if > necessary. > > https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add > your svn id. Proposers do not need to do it as they are indeed there > as +1 already (I added myself as example) > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52686 — Dmitry Stogov — 2011-06-01T16:47:03+00:00 URL: https://externals.io/message/52647#52686 · In reply to: #52652 Before now each major (5.y+1) release introduced API changes. We just couldn't introduce literal tables, interned strings, etc without API changes. However such API breaks where invisible for user-land and most extensions, they required a lot of changes in O+, APC, xdebug, etc. But, in case we freeze the API we just won't be able to add many future improvements. Thanks. Dmitry. > That isn't measurable, so it is a suggestion, not a standard. It also creates serious problems in userland if APIs change. API changes lead hosts to literally take years to update to new versions of PHP, for fear of breaking the sites that host with them. What about: > > Userland API compatibility of documented interfaces and behaviors must be kept. API internals should be backwards compatible wherever possible. > > This relaxes the userland restriction just slightly to allow for changes that break undocumented behaviors, but leaves it basically stable and measurable. This also leaves the door open for internal changes if they're really needed, but basically suggests against it. > > John Crenshaw > Priacta, Inc. > > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Wednesday, June 01, 2011 7:08 AM > To: Pierre Joye > Cc: PHP internals > Subject: Re: [PHP-DEV] Final version, RFC release process > > Hi, > > In my opinion a restriction "API compatibility must be kept (internals > and userland)" for x.y.z to x.y+1.z is too strict. It just can block > some new features forever. > > I would suggest to change "API compatibility must be kept" to "API > backward compatibility must be kept as much as possible". > > Thanks. Dmitry. --- ## #52687 — Stas Malyshev — 2011-06-01T16:50:32+00:00 URL: https://externals.io/message/52647#52687 · In reply to: #52686 Hi! > Before now each major (5.y+1) release introduced API changes. > We just couldn't introduce literal tables, interned strings, etc without > API changes. I think by API there it means PHP-level API, i.e. one exposed to the user, not binary API exposed to the extensions, which is meant by ABI. So what should be preserved is PHP function signatures, classes, syntax, INI settings, etc. but internals can change. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52688 — Zeev Suraski — 2011-06-01T16:52:59+00:00 URL: https://externals.io/message/52647#52688 · In reply to: #52687 There's something between the user level API and the ABI - which is source level compatibility. What Dmitry's pointing out that if we commit to source level compatibility, it'll be quite limiting (based on past experience). If we don't commit to source-level compatibility then we're fine. I guess we can say we'll strive for source level compatibility, but not have it as a 'must'. Zeev > -----Original Message----- > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com] > Sent: Wednesday, June 01, 2011 7:51 PM > To: Dmitry Stogov > Cc: John Crenshaw; PHP internals > Subject: Re: [PHP-DEV] Final version, RFC release process > > Hi! > > > […] > > I think by API there it means PHP-level API, i.e. one exposed to the user, not > binary API exposed to the extensions, which is meant by ABI. > So what should be preserved is PHP function signatures, classes, syntax, INI > settings, etc. but internals can change. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #52689 — Stas Malyshev — 2011-06-01T17:02:15+00:00 URL: https://externals.io/message/52647#52689 · In reply to: #52688 Hi! > There's something between the user level API and the ABI - which is source level compatibility. That's a good point. We'd like to keep source-level incompatibilities to a minimum - especially for simple extensions, not like APC :) - but I agree it may be hard to maintain at 100% if we do engine improvements. Maybe we should have different criteria for something like APC (which is very deep in the internals) and something like memcached (which needs much less from internals). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52690 — Pierre Joye — 2011-06-01T17:02:40+00:00 URL: https://externals.io/message/52647#52690 · In reply to: #52686 > Before now each major (5.y+1) release introduced API changes. > We just couldn't introduce literal tables, interned strings, etc without API > changes. > > However such API breaks where invisible for user-land and most extensions, > they required a lot of changes in O+, APC, xdebug, etc. > > But, in case we freeze the API we just won't be able to add many future > improvements. Userland BC must be kept between x.y and x.y+1, that's the primary goal of this section. PHP userland is only about API compatibility and how PHP behaves. However, what you refer to is about internals API. We can (and did a lot) break ABI between x.y and x.y+1 and should really avoid breaking API (read: signatures, source compatibility) if possible. To make it more clear, here are some good explanations about API and ABI: http://stackoverflow.com/questions/3784389/difference-between-api-and-abi http://en.wikipedia.org/wiki/Application_binary_interface http://en.wikipedia.org/wiki/Application_programming_interface -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52712 — Zeev Suraski — 2011-06-01T22:10:50+00:00 URL: https://externals.io/message/52647#52712 · In reply to: #52690 > However, what you refer to is about internals API. We can (and did a > lot) break ABI between x.y and x.y+1 and should really avoid breaking API > (read: signatures, source compatibility) if possible. I think we need to clear it up in the RFC. My take: - Switch from talking about 'ABI' to 'extension API' - Divide the extension API into source-level and binary-level - For x.y+1, make it clear that there's no need to retain binary-level extension API, and that source-level extension API is a 'should' and not a 'must'. Zeev --- ## #52718 — Pierre Joye — 2011-06-01T22:24:32+00:00 URL: https://externals.io/message/52647#52718 · In reply to: #52712 > > […] > > I think we need to clear it up in the RFC.  My take: > > - Switch from talking about 'ABI' to 'extension API' > - Divide the extension API into source-level and binary-level > - For x.y+1, make it clear that there's no need to retain binary-level extension API, and that source-level extension API is a 'should' and not a 'must'. On it, adding the reference to ABI/API definition as well. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52722 — Christopher Jones — 2011-06-01T22:34:14+00:00 URL: https://externals.io/message/52647#52722 · In reply to: #52647 > URL: https://wiki.php.net/rfc/releaseprocess Pierre, There are some immediately practical things here. Some things will be a large jolt for the community and might be better introduced in future releases. Chris Good: - Scheduled releases - Use of RFCs - No PHP script breakages in x.y.z+1 releases Too complex or not good: - Number of concurrent branches: Johannes's suggestion was good - Secret voting & automated polls: many things are not binary decisions and need discussion - Feature preview release: good in theory. Is there any need to formalize this since anyone can create a patch (or fork etc)? Define & clarify for the lay reader: - "External API", "Internal API", ABI, "internals", "userland" -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #52724 — Pierre Joye — 2011-06-01T22:46:13+00:00 URL: https://externals.io/message/52647#52724 · In reply to: #52722 hi Chris On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones wrote: > > > > > > […] > > Pierre, > > There are some immediately practical things here.  Some things will > be a large jolt for the community and might be better introduced in > future releases. > > Chris > > Good: >  - Scheduled releases >  - Use of RFCs >  - No PHP script breakages in x.y.z+1 releases > > Too complex or not good: >  - Number of concurrent branches: Johannes's suggestion was good This proposal for distros not for programming languages or similar tools. All users I talk to need fixed timeline, life cycle, etc. to have a clear and plan-able way to deal with php versions. >  - Secret voting & automated polls: many things are not binary >    decisions and need discussion There is no secret voting. >  - Feature preview release: good in theory.  Is there any need to >    formalize this since anyone can create a patch (or fork etc)? Yes, just to explain what it is and tell devs they can do it and (< that's important) publish it. > Define & clarify for the lay reader: >  - "External API", "Internal API", ABI, "internals", "userland" On it :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52734 — Peter Lind — 2011-06-02T05:32:26+00:00 URL: https://externals.io/message/52647#52734 · In reply to: #52724 > > hi Chris > > On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones > wrote: > > […] > > This proposal for distros not for programming languages or similar > tools. All users I talk to need fixed timeline, life cycle, etc. to > have a clear and plan-able way to deal with php versions. > Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's nothing random at all about their release process. There are fixed timelines and life cycles in Ubuntu - having less branches does not in any way stop them from having a fixed release process and schedule. Regards Peter --- Next page: https://externals.io/message/52647.md?page=2