# HEADS UP: Upcoming Feature Freeze for PHP 5.5.0 - Thread: https://externals.io/message/65152 - Original archive: https://news-web.php.net/php.internals/65152 - Started by David Soria Parra on 2013-01-24T21:39:17+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/65152.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 --- ## #65152 — David Soria Parra — 2013-01-24T21:39:17+00:00 URL: https://externals.io/message/65152#65152 Hi Internals, as you might have read in the 5.5.0alpha4 announcments, we are moving forward with 5.5.0. We are already a bit late on the schedule and we want to begin the beta cycle in 14 days and concentrate on QA for the 5.5.0 release from now on. This includes a feature freeze. No new features should be comitted to the repository once we tagged the first beta on Feb 7. All outstanding features will have to wait for 5.6.0 in a year unless there is a really good reason for an exception. Feature Freeze is on Feb 7, 2013. Regards, Julien and David --- ## #65156 — Kalle Sommer Nielsen — 2013-01-25T06:22:14+00:00 URL: https://externals.io/message/65152#65156 · In reply to: #65152 Hi 2013/1/24 David Soria Parra : > This includes a feature freeze. No new features should be comitted to > the repository once we tagged the first beta on Feb 7. All outstanding > features will have to wait for 5.6.0 in a year unless there is a This reminds me of yet another old topic: http://www.serverphorums.com/read.php?7,374842 and the one before: http://markmail.org/message/4w6lcbunw3qfof3c TL;DR, I think it is time to include APC in the core as we so many times have talked about and most people have agreed, dating back to the 6.0 meeting in '05 even. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #65157 — Sherif Ramadan — 2013-01-25T06:33:07+00:00 URL: https://externals.io/message/65152#65157 · In reply to: #65156 > Hi > > 2013/1/24 David Soria Parra : > > […] > > This reminds me of yet another old topic: > http://www.serverphorums.com/read.php?7,374842 > > and the one before: > http://markmail.org/message/4w6lcbunw3qfof3c > > > TL;DR, I think it is time to include APC in the core as we so many > times have talked about and most people have agreed, dating back to > the 6.0 meeting in '05 even. > From what I understood from Rasmus the biggest challenge with merging APC into core is the fact that the compiler currently isn't built to support opcode caching. One of the challenges he pointed out was some of the MAKE_NOP trickery that can make APC's work a bit more complex than necessary. It's possible to optimize the compiler enough to the point that APC's code could be reduced down to very simple opcode caching, putting less stress on the engine and making it easier to maintain. So far from what I've seen by looking at APC's code is that this problem isn't trivial to solve without improving the compiler and makes APC's code a bit bloated. It's also not easy to debug APC either. Judging by the bug reports on bugs web, many of these bugs are also not trivial to reproduce let alone debug and fix. I think that APC should eventually be reduced down to a simple opcode cache and merged into core, but I also think that Rasmus is right about improving the compiler to make opcode caching simpler so that APC doesn't have to do all these tricks. > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net --- ## #65158 — Ralf Lang — 2013-01-25T07:56:33+00:00 URL: https://externals.io/message/65152#65158 · In reply to: #65157 > From what I understood from Rasmus the biggest challenge with merging APC > into core is the fact that the compiler currently isn't built to support > opcode caching. One of the challenges he pointed out was some of the > MAKE_NOP trickery that can make APC's work a bit more complex than > necessary. It's possible to optimize the compiler enough to the point that > APC's code could be reduced down to very simple opcode caching, putting > less stress on the engine and making it easier to maintain. I think there was some support for moving APC first from pecl to the PHP standard distribution's ext folder before any tighter integration is started. --- ## #65159 — Rasmus Lerdorf — 2013-01-25T08:19:34+00:00 URL: https://externals.io/message/65152#65159 · In reply to: #65158 > > […] > > I think there was some support for moving APC first from pecl to the PHP > standard distribution's ext folder before any tighter integration is > started. I'm really not convinced that by moving it to core we will magically get people to help with it. I have been trying to get people interested for years, and it hasn't gotten very far. Everyone wants it in the core, but with a couple of exceptions, nobody is willing to actually work on it to get it there. And I can understand the lack of help. It is probably the most complicated piece of the entire stack. It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded. It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way. So the learning curve is steep and the bugs are extremely hard to track down because it is the only PHP component that isn't a perfect sandbox. A slight memory corruption almost anywhere in any extension can segfault a dozen requests later with a backtrace that points to the opcode cache code. Not to mention web servers like Apache that longjmp() on us at the wrong time. Zend-signals addresses this, but even in 5.4 they aren't enabled by default because of stability issues and without those no shared memory opcode cache is safe. I firmly believe that we need opcode caching in core. I'm rather skeptical that simply moving pecl/apc to ext/apc is going to help users in any way. People have no trouble finding and installing APC today. The real issue here is robustness and lag time between a PHP release and and solid APC release and that has to do with resources which are scarce due to the code complexity. This is the real problem we need to solve. Either by a number of people stepping up to help with the existing APC code, or perhaps more realistically making it a priority in PHP 5.6 to streamline the engine and the executor for opcode caching and either including a heavily simplified version of APC or writing a new one. One thing I can guarantee is that if we add it to core in its current condition it will delay 5.5 by 6+ months if not longer. -Rasmus --- ## #65160 — Pierre Joye — 2013-01-25T09:33:28+00:00 URL: https://externals.io/message/65152#65160 · In reply to: #65159 > > > Either by a number of people stepping up to help with the existing APC > code, or perhaps more realistically making it a priority in PHP 5.6 to > streamline the engine and the executor for opcode caching and either > including a heavily simplified version of APC or writing a new one. Cannot agree more. > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. Same here, I cannot agree more, it exactly matches my thoughts. Cheers, -- Pierre --- ## #65161 — Julien Pauli — 2013-01-25T10:37:21+00:00 URL: https://externals.io/message/65152#65161 · In reply to: #65159 > > > […] > APC > > […] > that > > […] > > I'm really not convinced that by moving it to core we will magically get > people to help with it. I have been trying to get people interested for > years, and it hasn't gotten very far. Everyone wants it in the core, but > with a couple of exceptions, nobody is willing to actually work on it to > get it there. > > And I can understand the lack of help. It is probably the most > complicated piece of the entire stack. It is a an op_array juggler doing > a complex dance on a tight rope backwards and blindfolded. It is > essentially multi-threaded in that there are multiple processes all > reading and writing the same chunk of memory while dealing with a > compiler that spits out context-sensitive op_arrays that were never > designed to be cached and executed this way. > > So the learning curve is steep and the bugs are extremely hard to track > down because it is the only PHP component that isn't a perfect sandbox. > A slight memory corruption almost anywhere in any extension can segfault > a dozen requests later with a backtrace that points to the opcode cache > code. Not to mention web servers like Apache that longjmp() on us at the > wrong time. Zend-signals addresses this, but even in 5.4 they aren't > enabled by default because of stability issues and without those no > shared memory opcode cache is safe. > > I firmly believe that we need opcode caching in core. I'm rather > skeptical that simply moving pecl/apc to ext/apc is going to help users > in any way. People have no trouble finding and installing APC today. The > real issue here is robustness and lag time between a PHP release and and > solid APC release and that has to do with resources which are scarce due > to the code complexity. This is the real problem we need to solve. > Either by a number of people stepping up to help with the existing APC > code, or perhaps more realistically making it a priority in PHP 5.6 to > streamline the engine and the executor for opcode caching and either > including a heavily simplified version of APC or writing a new one. > That feels like a safe idea. I'm convinced that having more internals documentation will help developpers understand at least the engine (that's what interest us here). I know it's a hard task, but we all here have blogs where sometimes we write great articles about a part of internals, I think we should focus on working alltogether writing a real technical doc for the engine, that will help people (like me for example), understand some dark parts of it, and then find ideas or solutions for it to evolve the right way. > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. > Ok that seems clear. Julien.Pauli --- ## #65162 — Thomas Bley — 2013-01-25T11:55:50+00:00 URL: https://externals.io/message/65152#65162 · In reply to: #65159 > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. I think it is fine if APC doesn't support all features of PHP. When there is a clear documentation, everybody can decide if he skips some features for better performance. Maybe this also offers room for more optimizations. Regards, Thomas > > > […] > > I'm really not convinced that by moving it to core we will magically get > people to help with it. I have been trying to get people interested for > years, and it hasn't gotten very far. Everyone wants it in the core, but > with a couple of exceptions, nobody is willing to actually work on it to > get it there. > > And I can understand the lack of help. It is probably the most > complicated piece of the entire stack. It is a an op_array juggler doing > a complex dance on a tight rope backwards and blindfolded. It is > essentially multi-threaded in that there are multiple processes all > reading and writing the same chunk of memory while dealing with a > compiler that spits out context-sensitive op_arrays that were never > designed to be cached and executed this way. > > So the learning curve is steep and the bugs are extremely hard to track > down because it is the only PHP component that isn't a perfect sandbox. > A slight memory corruption almost anywhere in any extension can segfault > a dozen requests later with a backtrace that points to the opcode cache > code. Not to mention web servers like Apache that longjmp() on us at the > wrong time. Zend-signals addresses this, but even in 5.4 they aren't > enabled by default because of stability issues and without those no > shared memory opcode cache is safe. > > I firmly believe that we need opcode caching in core. I'm rather > skeptical that simply moving pecl/apc to ext/apc is going to help users > in any way. People have no trouble finding and installing APC today. The > real issue here is robustness and lag time between a PHP release and and > solid APC release and that has to do with resources which are scarce due > to the code complexity. This is the real problem we need to solve. > Either by a number of people stepping up to help with the existing APC > code, or perhaps more realistically making it a priority in PHP 5.6 to > streamline the engine and the executor for opcode caching and either > including a heavily simplified version of APC or writing a new one. > > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. > > -Rasmus --- ## #65163 — Sebastian Krebs — 2013-01-25T12:15:35+00:00 URL: https://externals.io/message/65152#65163 · In reply to: #65162 2013/1/25 Thomas Bley > > […] > > I think it is fine if APC doesn't support all features of PHP. When > there is a clear documentation, everybody can decide if he skips some > features for better performance. Maybe this also offers room for more > optimizations. > You cannot simply decide, what features you want to use, when you rely on third-party-libraries from time to time. > > Regards, > Thomas > > > On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf > wrote: > > […] > APC > > […] > support > > […] > that > > […] > > -- > > > > -- github.com/KingCrunch --- ## #65164 — Thomas Bley — 2013-01-25T12:25:08+00:00 URL: https://externals.io/message/65152#65164 · In reply to: #65163 > You cannot simply decide if you cannot decide, you can run tests or turn it off. Having it off by default would be the same as today. Most people activate apc without further thinking. Regards, Thomas > > > > 2013/1/25 Thomas Bley > > […] > > > You cannot simply decide, what features you want to use, when you rely on > third-party-libraries from time to time. > > > […] > > > > -- > github.com/KingCrunch --- ## #65165 — Clint Priest — 2013-01-25T12:30:04+00:00 URL: https://externals.io/message/65152#65165 · In reply to: #65161 > > > > […] I'm not sure if anyone has a deep understanding of APC and the problems the existing compiler design causes for it, perhaps another great place to start on this project is to get a list of the high-level problems the compiler does or doesn't do that could be changed. Then we can break those down and identify the parts of the engine that will require some re-work. > > […] > That feels like a safe idea. I'm convinced that having more internals > documentation will help > developpers understand at least the engine (that's what interest us here). I agree that bringing some more documentation can only help; people with less experience or who have missing areas of expertise in the core will more easily be able to step up and help with the problem. > I know it's a hard task, but we all here have blogs where sometimes we > write great articles > about a part of internals, I think we should focus on working alltogether > writing a real technical doc for the engine, > that will help people (like me for example), understand some dark parts of > it, and then find ideas or solutions for it to > evolve the right way. This may only be my perception, but in having to learn what I did for the failed accessors project I felt like there were 2 or 3 more or less identical ways the compiler and/or executor was doing the same thing. Without further understanding I presumed it was because as time went by a new "way" was added because the old way just wasn't enough. In essence adding to the technical debt. Possibly/probably just a misconception of my own but that's the way it felt. I'd be happy to jump in and help fix this in any way I can but I don't even know where the string starts or what it looks like to unravel the problem at this point. -- -Clint --- ## #65169 — Levi Morrison — 2013-01-25T15:44:39+00:00 URL: https://externals.io/message/65152#65169 · In reply to: #65159 > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. I am not familiar with the details of opcodes at all, let alone APC. However, I think it would be wise to delay major core changes for APC until the next major version of PHP. I don't think a minor release is appropriate for this kind of change because of the amount of possible breakage. This is just my opinion, of course. --- ## #65171 — Zeev Suraski — 2013-01-25T16:25:37+00:00 URL: https://externals.io/message/65152#65171 · In reply to: #65159 > Either by a number of people stepping up to help with the existing APC code, or > perhaps more realistically making it a priority in PHP 5.6 to streamline the > engine and the executor for opcode caching and either including a heavily > simplified version of APC or writing a new one. > > One thing I can guarantee is that if we add it to core in its current condition it > will delay 5.5 by 6+ months if not longer. There's another option. We have the Optimizer+ component which is current, a bit faster than APC, worked with PHP 5.4 from the get go and already fully supports 5.5 - and now that it's been free for use for several years, we'd actually be happy to opensource it and make it a part of core. An extra benefit would be that we'd commit to maintain it, although of course, community contribution will be very welcome. Here too, it's code with a very long history, some of which even predates PHP 4.0. But It Works(tm), and we could put some effort into cleaning it up and beautifying it. I think we can actually do it on time for 5.5.0, or with a relatively minor delay that might be worth it. I'm sure most users would prefer the version to take a bit longer if it comes with an opcode cache right off the bat. There'll most probably be APIs we'd want to merge from APC, but doing that should be easy - and we can get the good of both worlds. Zeev --- ## #65172 — Will Fitch — 2013-01-25T16:47:47+00:00 URL: https://externals.io/message/65152#65172 · In reply to: #65171 > > […] > code, or > > […] > the > > […] > heavily > > […] > condition it > > […] > > There's another option. We have the Optimizer+ component which is > current, a bit faster than APC, worked with PHP 5.4 from the get go and > already fully supports 5.5 - and now that it's been free for use for > several years, we'd actually be happy to opensource it and make it a part > of core. An extra benefit would be that we'd commit to maintain it, > although of course, community contribution will be very welcome. > Here too, it's code with a very long history, some of which even predates > PHP 4.0. But It Works(tm), and we could put some effort into cleaning it > up and beautifying it. I like the idea. If this was implemented in core, and the need for APC opcode caching disappeared, would APC still be actively maintained for userland functions (e.g. apc_store, apc_*)? > I think we can actually do it on time for 5.5.0, or with a relatively > minor delay that might be worth it. I'm sure most users would prefer the > version to take a bit longer if it comes with an opcode cache right off > the bat. > There'll most probably be APIs we'd want to merge from APC, but doing that > should be easy - and we can get the good of both worlds. > > Zeev --- ## #65173 — Derick Rethans — 2013-01-25T16:52:05+00:00 URL: https://externals.io/message/65152#65173 · In reply to: #65159 > …or perhaps more realistically making it a priority in PHP 5.6 to > streamline the engine and the executor for opcode caching and either > including a heavily simplified version of APC or writing a new one. I think that's probably one of the key points to take away here. Making things less complex for an opcode cache also benefits other tools. (Either with APC, or if we choose to pick Optimizer+) cheers, Derick --- ## #65174 — Julien Pauli — 2013-01-25T16:52:54+00:00 URL: https://externals.io/message/65152#65174 · In reply to: #65172 > > > > > […] > > I like the idea. If this was implemented in core, and the need for APC > opcode caching disappeared, would APC still be actively maintained for > userland functions (e.g. apc_store, apc_*)? > Well, the APC idea was anyway to merge an Opcode cache to Core, and only an Opcode cache (correct if I'm wrong). apc_store() etc... are userland shared memory function, and should be migrated into another extensions, on which we could then allocate devs to work on, new ideas, etc... Julien.Pauli --- ## #65175 — Rasmus Lerdorf — 2013-01-25T17:16:11+00:00 URL: https://externals.io/message/65152#65175 · In reply to: #65171 > There's another option. We have the Optimizer+ component which is > current, a bit faster than APC, worked with PHP 5.4 from the get go and > already fully supports 5.5 - and now that it's been free for use for > several years, we'd actually be happy to opensource it and make it a part > of core. An extra benefit would be that we'd commit to maintain it, > although of course, community contribution will be very welcome. > Here too, it's code with a very long history, some of which even predates > PHP 4.0. But It Works(tm), and we could put some effort into cleaning it > up and beautifying it. > I think we can actually do it on time for 5.5.0, or with a relatively > minor delay that might be worth it. I'm sure most users would prefer the > version to take a bit longer if it comes with an opcode cache right off > the bat. > There'll most probably be APIs we'd want to merge from APC, but doing that > should be easy - and we can get the good of both worlds. I would be ok with that. The goal here is opcode cacheing in core. How we get there is less important. The one thing we can do bringing an old codebase into core is to clean it up quite a bit since we'd know the target version. All the ifdefs for older versions can go away, and some of the tricks that need to be done could be shuffled into the compiler/executor to streamline things. I am also not worried about userspace compatibility for things like apc_store/fetch. Any software written to make use of that already has conditional checks around it plus that feature needs a serious re-think anyway. Sharing a lock with op_array handling really doesn't scale. -Rasmus --- ## #65176 — Zeev Suraski — 2013-01-25T17:18:21+00:00 URL: https://externals.io/message/65152#65176 · In reply to: #65172 > -----Original Message----- > From: Will Fitch [mailto:wfitch@meetme.com] On Behalf Of Will Fitch > Sent: Friday, January 25, 2013 6:48 PM > To: Zeev Suraski; Rasmus Lerdorf > Cc: Ralf Lang; internals@lists.php.net > Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0 > > > > > > […] welcome. > > […] > > I like the idea. If this was implemented in core, and the need for APC opcode > caching disappeared, would APC still be actively maintained for userland > functions (e.g. apc_store, apc_*)? We could either do that, or create some sort of a merge between the two projects and take the apc_*() APIs into a combined module. I think that would give us the best of both worlds. Zeev --- ## #65177 — Sean Coates — 2013-01-25T17:21:37+00:00 URL: https://externals.io/message/65152#65177 · In reply to: #65175 > Any software written to make use of that already has > conditional checks around it plus that feature needs a serious re-think > anyway. FWIW, we only deploy with APC, so we don't necessarily have checks guarding apc_fetch()/apc_store(). That said, it would be trivial to write wrapper functions that call a different API if they were compatible in any way. S --- ## #65178 — Zeev Suraski — 2013-01-25T17:30:45+00:00 URL: https://externals.io/message/65152#65178 · In reply to: #65175 > -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Friday, January 25, 2013 7:16 PM > To: Zeev Suraski > Cc: Ralf Lang; internals@lists.php.net > Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0 > > > > > […] > > I would be ok with that. The goal here is opcode cacheing in core. How we > get > there is less important. The one thing we can do bringing an old codebase > into > core is to clean it up quite a bit since we'd know the target version. All > the ifdefs > for older versions can go away, and some of the tricks that need to be > done > could be shuffled into the compiler/executor to streamline things. I agree. It would probably make sense to only maintain it for 5.5.0, or perhaps both 5.4.0 and 5.5.0 since those will be the two supported versions for years to come. No real point in supporting 5.3 and earlier, and I bet we can clean things quite a bit with such an assumption. Tighter integration may also prove helpful. > I am also not worried about userspace compatibility for things like > apc_store/fetch. Any software written to make use of that already has > conditional checks around it plus that feature needs a serious re-think > anyway. > Sharing a lock with op_array handling really doesn't scale. Ideally I think we'll want to have some sort of continuity, so we could either keep APC available as a data-cache-only extension (either in core or outside), or merge this code together with Optimizer+. One other thing we may consider is our data caching component, which is already decoupled from Optimizer+, and exposes APC-compatible APIs - we can look into opensourcing it as well (it's already free today). Zeev --- ## #65179 — Will Fitch — 2013-01-25T17:40:29+00:00 URL: https://externals.io/message/65152#65179 · In reply to: #65174 > > > > > > […] > > I like the idea. If this was implemented in core, and the need for APC opcode caching disappeared, would APC still be actively maintained for userland functions (e.g. apc_store, apc_*)? > > Well, the APC idea was anyway to merge an Opcode cache to Core, and only an Opcode cache (correct if I'm wrong). > apc_store() etc... are userland shared memory function, and should be migrated into another extensions, on which we could then allocate devs to work on, new ideas, etc… No, you're right. With Optimizer+ showing a slightly better performance than APC, being "privately" and publicly maintained, open-sourced, already compatible up to 5.5, I see it as a great candidate for core integration. I'd still like to keep APC as a separate extension, but packaged with PHP, for data-only caching. @Zeev, is anyone writing up an RFC for this? > > Julien.Pauli --- ## #65180 — Zeev Suraski — 2013-01-25T18:10:24+00:00 URL: https://externals.io/message/65152#65180 · In reply to: #65179 > @Zeev, is anyone writing up an RFC for this? Not yet, I'll write one. Zeev --- ## #65182 — Pierre Joye — 2013-01-25T18:42:20+00:00 URL: https://externals.io/message/65152#65182 · In reply to: #65171 hi Zeev, > > […] > code, or > > […] > the > > […] > heavily > > […] > condition it > > […] > > There's another option. We have the Optimizer+ component which is > current, a bit faster than APC, worked with PHP 5.4 from the get go and > already fully supports 5.5 - and now that it's been free for use for > several years, we'd actually be happy to opensource it and make it a part > of core. An extra benefit would be that we'd commit to maintain it, > although of course, community contribution will be very welcome. > Here too, it's code with a very long history, some of which even predates > PHP 4.0. But It Works(tm), and we could put some effort into cleaning it > up and beautifying it. Thanks, That sounds great. > I think we can actually do it on time for 5.5.0, or with a relatively > minor delay that might be worth it. I'm sure most users would prefer the > version to take a bit longer if it comes with an opcode cache right off > the bat. > There'll most probably be APIs we'd want to merge from APC, but doing that > should be easy - and we can get the good of both worlds. Please don't bring over the user cache, please don't :-) Quesiton: Does it support both NTS and TS? Cheers, -- Pierre @pierrejoye --- ## #65183 — Stas Malyshev — 2013-01-25T18:44:49+00:00 URL: https://externals.io/message/65152#65183 · In reply to: #65171 Hi! > There's another option. We have the Optimizer+ component which is > current, a bit faster than APC, worked with PHP 5.4 from the get go and > already fully supports 5.5 - and now that it's been free for use for > several years, we'd actually be happy to opensource it and make it a part > of core. An extra benefit would be that we'd commit to maintain it, That would be excellent! I probably also could be of some help here, if its needed, since I'm familiar with the codebase (while my knowledge of the APC code is minimal). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #65184 — Zeev Suraski — 2013-01-25T18:48:39+00:00 URL: https://externals.io/message/65152#65184 · In reply to: #65182 > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Friday, January 25, 2013 8:42 PM > To: Zeev Suraski > Cc: Rasmus Lerdorf; Ralf Lang; PHP internals > Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0 > > hi Zeev, > > > > […] welcome. > > […] > > Thanks, That sounds great. > > > […] > > Please don't bring over the user cache, please don't :-) Sounds like there's concensus we don't want these things coupled, so we should probably handle that part separately :) > > Quesiton: Does it support both NTS and TS? I think it used to but if it did that part hasn't been maintained for a very long time. Not sure where it stands right now... Zeev --- Next page: https://externals.io/message/65152.md?page=2