On 21/11/12 15:47, Adam Harvey wrote:
On 19 November 2012 20:44, Anthony Ferrara <ircmax...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
