Re: RFC: ext/mysql deprecation

From: Date: Wed, 21 Nov 2012 05:03:56 +0000
Subject: Re: RFC: ext/mysql deprecation
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-64003@lists.php.net to get a copy of this message
On 21/11/12 15:47, Adam Harvey wrote:
On 19 November 2012 20:44, Anthony Ferrara <ircmaxell@gmail.com> wrote:
My intention at this stage is to call a vote next Monday: it feels like the discussion has mostly died down now (which isn't to say I think we're at a consensus necessarily — it just feels as though the flurry of opinions have been made and argued either way), and I'm hoping that everyone can have a think about where and how they'd like to see this move forward (if at all) between now and then. Given we've only just hit alpha 1, I don't think we need to rush into a decision right now for the sake of one.
I completely agree. I would suggest one thing though. When it comes up for a vote, please either make 2 questions: 1. Should ext/mysql be hard-deprecated in 5.5 2. Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT Or 4 options to deprecation: 1. Hard-deprecated in 5.5 2. Soft-deprecated in 5.5 and hard-deprecated in NEXT 3. Either 4. Neither That way both viewpoints can be voted on in one vote. And we can get an accurate count of the thoughts...
I've been mulling this for a couple of days, and Anthony and I have talked about this on IRC, and I'd prefer to have two questions: 1. Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no) 2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what should the next course of action be: (a) Enhance the manual text to make the soft deprecation clearer, and generate E_DEPRECATED notices in PHP 5.6 (b) Enhance the manual text to make the soft deprecation clearer, but take no further action in terms of E_DEPRECATED for the forseeable future (c) Remove the warnings from the manual and undeprecate ext/mysql entirely The reason for this is that I'd like to make the vote about the actual RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3 or 4 option vote there could easily lead to a split decision, which will make it very difficult to take any sort of decisive action. I'd rather make a decision there, then we can look at what action would be preferred if the RFC itself fails. Just to be clear: I don't think that "do nothing" is a very useful option for the second question, which is why I've omitted it — it doesn't seem like anyone's particularly satisfied with the current state of affairs. Thoughts? Adam
Has 2(c) been even suggested? I take at that 2(b) is for those advocating "Move to PECL with no E_DEPRECATED notices being thrown"? Cheers, David

« previous php.internals (#64003) next »