Hi internals,
I'm happy to announce that the RFC was accepted with 17 votes for and 2
against. The secondary vote about introducing a deprecation notice on 7.3
was rejected.
I have moved the RFC to a new section for accepted PHP 8.0 RFCs under the
Pending Implementation section.
You can find the
Am 12.06.2017 um 08:14 schrieb Davey Shafik:
> It would be best to just kill the vote and start over. The proposal should
> be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should
> be one vote, as doing both together should be the only option.
+1
--
PHP Internals - PHP Runtim
Pedro,
It would be best to just kill the vote and start over. The proposal should
be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should
be one vote, as doing both together should be the only option.
- Davey
On Sun, Jun 11, 2017 at 8:25 AM, Pedro Magalhães wrote:
> On Thu,
On Thu, Jun 8, 2017 at 9:52 AM, François Laupretre wrote:
>
> I am sorry you take it this way. Voting today on a feature for 8.0
> wouldn't be ridiculous and it would make me change my vote, as most others.
> Instead of nonsense, it would be a sign of maturity for the PHP project. It
> would be gr
On 10.06.2017 at 21:29, Rowan Collins wrote:
> On 8 June 2017 08:52:41 BST, "François Laupretre" wrote:
>> It would be great, IMO, to open a 'Approved for 8.0' section
>> on
>> the RFC page now, and your RFC could proudly be the 1st one to enter
>> it.
>
> I definitely agree with this, as I've
On 8 June 2017 08:52:41 BST, "François Laupretre" wrote:
> It would be great, IMO, to open a 'Approved for 8.0' section
>on
>the RFC page now, and your RFC could proudly be the 1st one to enter
>it.
I definitely agree with this, as I've argued before for a more timeline based
approach to major
Hi Pedro,
Le 07/06/2017 à 20:23, Pedro Magalhães a écrit :
I will not change the target version now during the voting phase. Also
because it wouldn't make sense to vote for a feature for 8.0 yet. If the
RFC is rejected and the sentiment is that most people would agree with
the change but not w
Am 07.06.2017 um 16:23 schrieb Pedro Magalhães:
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
wrote:
you can't simply pass something that *incidentally* changes a
pre-established rule
Hi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprec
On 6/7/2017 8:23 PM, Pedro Magalhães wrote:
> I will not change the target version now during the voting phase. Also
> because it wouldn't make sense to vote for a feature for 8.0 yet. If the
> RFC is rejected and the sentiment is that most people would agree with the
> change but not with the timi
On Wed, Jun 7, 2017 at 2:41 PM, François Laupretre
wrote:
>
> So, I respectfully ask you to change target to PHP 8 or explain why we
> should make an exception to the process. Reasons you gave so far are OK for
> a major version, but not for a minor one. This is not against you or your
> work, as
On 7 June 2017 17:36:01 BST, "Pedro Magalhães" wrote:
>On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins
>wrote:
>
>> On 7 June 2017 15:23:13 BST, "Pedro Magalhães"
>wrote:
>> >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
>
>> >wrote:
>> >
>> >> you can't simply pass something that *incidentally* c
On Wed, Jun 7, 2017 at 5:38 PM, Rowan Collins
wrote:
> On 7 June 2017 15:23:13 BST, "Pedro Magalhães" wrote:
> >On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
> >wrote:
> >
> >> you can't simply pass something that *incidentally* changes a
> >> pre-established rule
> >
> >
> >Hi Rowan,
> >
> >Wo
On 7 June 2017 15:23:13 BST, "Pedro Magalhães" wrote:
>On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
>wrote:
>
>> you can't simply pass something that *incidentally* changes a
>> pre-established rule
>
>
>Hi Rowan,
>
>Would you consider that that is not the case for your own RFC?
>https://wiki.ph
On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins
wrote:
> you can't simply pass something that *incidentally* changes a
> pre-established rule
Hi Rowan,
Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings
On 07.06.2017 at 15:32, Dan Ackroyd wrote:
> On 7 June 2017 at 13:41, François Laupretre wrote:
>
>> Right. Introducing this change is not compatible with the release process,
>> whatever the result of the vote... explain why we
>> should make an exception to the process.
>
> The RFC process is
On 7 June 2017 14:32:50 BST, Dan Ackroyd wrote:
>The RFC process is the way that we change the rules, and RFCs are not
>constrained by any previous RFC or by any 'constitution' as PHP
>doesn't have one. This is similar to how the UK parliament isn't
>constrained by any previous decision or constit
On 7 June 2017 at 13:41, François Laupretre wrote:
> Hi,
>
> Right. Introducing this change is not compatible with the release process,
> whatever the result of the vote... explain why we
> should make an exception to the process.
The RFC process is the way that we change the rules, and RFCs are
Hi,
Right. Introducing this change is not compatible with the release
process, whatever the result of the vote.
So, I respectfully ask you to change target to PHP 8 or explain why we
should make an exception to the process. Reasons you gave so far are OK
for a major version, but not for a mi
On 06.06.2017 at 19:55, Pedro Magalhães wrote:
> Hi all,
>
> I have just opened the vote on this RFC.
>
> The main goal of the RFC is to eliminate the inconsistency in arrays when
> negative numeric keys are used explicitly and the following implicit keys
> will start from zero.
>
> You can fin
19 matches
Mail list logo
