On Thu, Nov 29, 2012 at 3:57 PM, David Muir <davidkm...@gmail.com> wrote:
> On 30/11/12 05:25, Ángel González wrote: > > On 29/11/12 18:17, Anthony Ferrara wrote: > >> Just pointing this out: that's NOT what this RFC recommends, and is > >> NOT what's being voted on. This RFC is talking about ONLY adding > >> E_DEPRECATED to core. And the way it's proposed to be done, the > >> "moves-to-PECL" couldn't happen, since it's hard-coded into the core > >> extension... > >> > >> So be careful what you're voting for... > > The RFC doesn't state if/when ext/mysql should be moved to pecl or if it > > should or not throw E_DEPRECATED there. > > It was stated in one of the previous threads that: > > - The extension would be moved to PECL when removed from core. > > - It's ok if you want to use ext/mysql from pecl as it's "unsupported" > > and your own problem, not one of php developers. > > > > There were also concerns that throwing E_DEPRECATED didn't allow to > > cleanly use it (if you really wanted to) as if it was simply moved to > pecl. > > > > I was presenting a way to throw E_DEPRECATED (assuming that option wins > > in the RFC) while also allowing an extension (typically hosted on PECL) > > to “provide” the non-E_DEPRECATED extension. > > > > If you take a closer look, you will see that it can happen, as long as > > the core deprecation is done in that way, anticipating usage of that > > pecl extension. (Note that it is a variable which could only be changed > > by another extension, I wasn't proposing the ini_set mentioned by Alan, > > IMHO that's an uglier solution, since everybody would end up setting it). > > > > You are of course welcome to point out any failures in the pseudo-code I > > presented. :) > > There would be a dependency on ELF-like binaries if using weak symbols. > > But the version removing ext/mysql will likely have a different ABI > > anyway, so it's not a big problem to require a recompile of pecl/mysql > > for the different php version. > > > > This is exactly why it doesn't make sense to have a vote on E_DEPRECATED > without understanding what the future action will be. > > I might have missed some as there was no summary of the discussion in > the RFC, or a summary of the various positions. This should have been > added before calling a vote. Combined with future action, the various > positions as I've read them are: > > 1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing > E_DEPRECATED > 2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue > throwing E_DEPRECATED > 3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED > 4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT > > #1 means it's not really being deprecated > #2 kind of makes sense, but then why even move it to PECL? > #3 is consistent with current release RFC process > #4 is the type of case E_DEPRECATED is meant to handle (or has handled > thus far) > > The current release process RFC states: > > * > *x.y.z to x.y+1.z* > o > Bugfixes > o > New features > o > *Extensions support can be ended (moved to pecl)* > o > Backward compatibility must be kept > o > API compatibility must be kept (userland) > o > ABI and API can be broken (internals), src compatibility > should be kept if possible, while breakages are allowed > > [emphasis mine] > > Some are saying that that E_DEPRECATED can/should be used for entire > extensions. That's fine and dandy if said extension is actually going to > be removed (not just retired to PECL, but dropped completely), but > somehow I think a lot more people would object to the current RFC if > that were the plan. > > Cheers, > David > I don't think it would be appropriate to remove ext/mysql (whether completely or just moved to PECL) at any point in the 5.x branch. My thinking is that 6.0 would be the time for major changes/BC like that to take place. Since that's probably still a ways off, my understanding was that we're limiting the scope to what should happen in 5.x in the form of deprecation/transition. If you don't think it should be [re]moved at all, then I would assume you'd want to vote no on deprecation anyway. And if you do think it should be taken out in some form or another, then either way deprecation prior to doing so would be the most sensible approach IMNSHO. That's why it seems logical to me that we first decide on when/whether to deprecate, then as we get closer to the next major version increment we can figure out how best to dispose of it (assuming we voted to deprecate in the first place). --Kris
