Lester Caine wrote on 09/11/2014 22:39:
On 09/11/14 21:59, Rowan Collins wrote:
None of which has anything to do with E_STRICT. Strict notices aren't
indications that behaviour has changed; since we have E_DEPRECATED, they
shouldn't even indicate behaviour is about to change; they just indicate
On 09/11/14 21:59, Rowan Collins wrote:
> None of which has anything to do with E_STRICT. Strict notices aren't
> indications that behaviour has changed; since we have E_DEPRECATED, they
> shouldn't even indicate behaviour is about to change; they just indicate
> that there might be a better way of
On 09/11/2014 20:48, Lester Caine wrote:
On 07/11/14 01:59, Christoph Becker wrote:
Nobody suggested to switch off error reporting. IMO, E_STRICT is
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future. Until this can be
done, it se
On 07/11/14 01:59, Christoph Becker wrote:
> Nobody suggested to switch off error reporting. IMO, E_STRICT is
> supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
> developer to modernize the code in the near future. Until this can be
> done, it seems to be perfectly fine to suppress
Lester Caine wrote:
> On 06/11/14 11:16, Christoph Becker wrote:
>>> Yes it is only a number, but a lot more problematic changes WERE pushed
through across those three versions which would have been much safer
handled by removing e_strict from PHP5.4 rather than trying to live with
Hi!
> - major BC break: major versions only. 5 major BC breaks allowed per major
> version.
I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If
that breaks your code, even one is too much. If your code is not
affected, why would you care if it's 5 or 15 or 150? I'm afraid thi
On Thu, Nov 6, 2014 at 2:32 PM, Christoph Becker wrote:
> Ferenc Kovacs wrote:
>
> > On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker
> wrote:
> >
> >> Lester Caine wrote:
> >>
> >>> Yes it is only a number, but a lot more problematic changes WERE pushed
> >>> through across those three version
Ferenc Kovacs wrote:
> On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker wrote:
>
>> Lester Caine wrote:
>>
>>> Yes it is only a number, but a lot more problematic changes WERE pushed
>>> through across those three versions which would have been much safer
>>> handled by removing e_strict from P
On 06/11/14 11:16, Christoph Becker wrote:
>> Yes it is only a number, but a lot more problematic changes WERE pushed
>> > through across those three versions which would have been much safer
>> > handled by removing e_strict from PHP5.4 rather than trying to live with
>> > both versions of PHP.
>
On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker wrote:
> Lester Caine wrote:
>
> > Yes it is only a number, but a lot more problematic changes WERE pushed
> > through across those three versions which would have been much safer
> > handled by removing e_strict from PHP5.4 rather than trying to
Lester Caine wrote:
> Yes it is only a number, but a lot more problematic changes WERE pushed
> through across those three versions which would have been much safer
> handled by removing e_strict from PHP5.4 rather than trying to live with
> both versions of PHP.
I don't see a problem with regard
On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs wrote:
> 2014.11.06. 2:46 ezt írta ("Andrea Faulds" ):
> >
> >
> > > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> > >
> > > Regardless of those, I think it would be worse from the users POV than
> our
> > > current policy where we target no BC br
On 06/11/14 02:27, Andrea Faulds wrote:
>> We have minor BC breaks (new errors. Slight behavior changes due to bug
>> fixes).
>> >
>> > But globally no, it makes end users work harder for migration, even worst
>> > for distros.
>> >
>> > See Debian f.e., they boost the adoption speed now, we fi
2014.11.06. 2:46 ezt írta ("Andrea Faulds" ):
>
>
> > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> >
> > Regardless of those, I think it would be worse from the users POV than
our
> > current policy where we target no BC breaks in minor/micro versions.
> > The only exception should be security
> On 6 Nov 2014, at 02:00, Pierre Joye wrote:
>
> We have minor BC breaks (new errors. Slight behavior changes due to bug
> fixes).
>
> But globally no, it makes end users work harder for migration, even worst for
> distros.
>
> See Debian f.e., they boost the adoption speed now, we finally
On Nov 6, 2014 11:46 AM, "Andrea Faulds" wrote:
>
>
> > On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
> >
> > Regardless of those, I think it would be worse from the users POV than
our
> > current policy where we target no BC breaks in minor/micro versions.
> > The only exception should be securi
> On 5 Nov 2014, at 20:34, Ferenc Kovacs wrote:
>
> Regardless of those, I think it would be worse from the users POV than our
> current policy where we target no BC breaks in minor/micro versions.
> The only exception should be security concerns (see the unserialize changes
> in 5.6 for such an
Hi,
On Thu, Nov 6, 2014 at 3:20 AM, Florian Margaine wrote:
> Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good
> idea?
Have you missed:
https://wiki.php.net/rfc/releaseprocess
?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Dev
2014.11.05. 21:21 ezt írta ("Florian Margaine" ):
>
> Hi list,
>
> I'd like to introduce thresholds of backwards compatibility breaks, i.e.
> maximum numbers of allowed BC breaks per version.
>
> Lester's mail from a couple days ago had me thinking about the BC breaks
> that occur now and then in a
Hi list,
I'd like to introduce thresholds of backwards compatibility breaks, i.e.
maximum numbers of allowed BC breaks per version.
Lester's mail from a couple days ago had me thinking about the BC breaks
that occur now and then in all the RFCs or all the mails I see these days.
Now, take what I
20 matches
Mail list logo
