2015.03.19. 18:40 ezt írta ("Dan Ackroyd" ):
>
> On 19 March 2015 at 17:14, François Laupretre wrote:
>
> > As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
> > Please note that the switch from E_DEPRECATED to fatal error won't
require
On Fri, Mar 20, 2015 at 1:21 PM, François Laupretre wrote:
> May I also add that it is not the first time people raise concerns about RFCs
> when vote starts. On different occasions, it was clear that most had not read
> the RFC before the vote was announced. I even have two RFCs which were
> p
May I also add that it is not the first time people raise concerns about RFCs
when vote starts. On different occasions, it was clear that most had not read
the RFC before the vote was announced. I even have two RFCs which were planned
for 7.0 and won't be in because I had to stop the vote and re
> De : Dan Ackroyd [mailto:dan...@basereality.com]
>
> On 19 March 2015 at 17:14, François Laupretre wrote:
>
> > As you may have noticed if you had a look at the RFC or twitter, I have
> decided to follow people's suggestion.
> > Please note that the switch from E_DEPRECATED to fatal error won'
On Fri, Mar 20, 2015 at 5:04 AM, Nikita Popov wrote:
> On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski wrote:
>
>> > On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote:
>> >
>> > You are being dumb here as well. We try to avoid breaking code in
>> > point releases. This BC break can only be done at a ma
Hi!
>> As you may have noticed if you had a look at the RFC or twitter, I have
>> decided to follow people's suggestion.
>> Please note that the switch from E_DEPRECATED to fatal error won't require
>> any new RFC/discussion/vote
>> as the fatal error is considered as approved. I just introduce
Dan Ackroyd wrote on 19/03/2015 18:11:
Rowan wrote:
>you should pause, make a cup of tea, and redraft the e-mail.
That was the redrafted version.
And yet it still accused another contributor of "being dumb", and
demanded they have access revoked. That is not a respectful or
proportional res
Hi Zeev,
On 19 March 2015 at 17:49, Zeev Suraski wrote:
> Technically, we're not allowed to move from from a working feature into a
> removed one without a deprecation phase.
Please can you point me to where this is written down? Please also
show me where it says that this rule cannot be over-r
On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski wrote:
> > On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote:
> >
> > You are being dumb here as well. We try to avoid breaking code in
> > point releases. This BC break can only be done at a major version.
>
> Technically, we're not allowed to move from
On Thu, Mar 19, 2015 at 11:49 AM, Zeev Suraski wrote:
>> On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote:
>>
>> You are being dumb here as well. We try to avoid breaking code in
>> point releases. This BC break can only be done at a major version.
>
> Technically, we're not allowed to move from from
On Thu, Mar 19, 2015 at 1:40 PM, Dan Ackroyd wrote:
> On 19 March 2015 at 17:14, François Laupretre wrote:
>
>> As you may have noticed if you had a look at the RFC or twitter, I have
>> decided to follow people's suggestion.
>> Please note that the switch from E_DEPRECATED to fatal error won't
Dan Ackroyd wrote on 19/03/2015 17:40:
On 19 March 2015 at 17:14, François Laupretre wrote:
As you may have noticed if you had a look at the RFC or twitter, I have decided
to follow people's suggestion.
Please note that the switch from E_DEPRECATED to fatal error won't require any
new RFC/di
> On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote:
>
> You are being dumb here as well. We try to avoid breaking code in
> point releases. This BC break can only be done at a major version.
Technically, we're not allowed to move from from a working feature into a
removed one without a deprecation
On 19 March 2015 at 17:14, François Laupretre wrote:
> As you may have noticed if you had a look at the RFC or twitter, I have
> decided to follow people's suggestion.
> Please note that the switch from E_DEPRECATED to fatal error won't require
> any new RFC/discussion/vote
> as the fatal erro
On Mar 20, 2015 12:14 AM, "François Laupretre" wrote:
>
> > De : Zeev Suraski [mailto:z...@zend.com]
> >
> > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
> > from our guidelines of deprecating features first, and removing them
> > later; It’s addressed in the RFC – but
> De : Zeev Suraski [mailto:z...@zend.com]
>
> https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
> from our guidelines of deprecating features first, and removing them
> later; It’s addressed in the RFC – but I’m a bit worried that this opens
> the door to jumping from any s
Hi all,
On Tue, Mar 3, 2015 at 2:30 AM, Julien Pauli wrote:
> On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT
> wrote:
>
> > Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit :
> >
> > > All,
> > >
> > >
> > >
> > > https://wiki.php.net/rfc/array-to-string (which I voted yes to)
> deviates
> >
On 2 March 2015 at 14:24, Zeev Suraski wrote:
> https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
> from our guidelines of deprecating features first, and removing them
> later;
>
> Should we not go through this deprecation cycle, even if may feel anxious
> to get rid of thi
On Mar 3, 2015 4:31 AM, "Julien Pauli" wrote:
> Same to me, I voted no because we're gonna break something which is not
> "that bad" and turn it to a clear breakage in one step.
> I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0
> and remove in 7.1 or 7.2 or whatever.
> We
On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT
wrote:
> Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit :
>
> > All,
> >
> >
> >
> > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
> > from our guidelines of deprecating features first, and removing them
> > later; It
Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit :
> All,
>
>
>
> https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
> from our guidelines of deprecating features first, and removing them
> later; It’s addressed in the RFC – but I’m a bit worried that this opens
> the door
21 matches
Mail list logo
