Pierre Joye wrote:
On Tue, Sep 11, 2012 at 12:23 AM, Stas Malyshev wrote:
>OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not
>everybody is going to upgrade to 5.5 soon, so having them participate
>would be good too. Maybe we could do it as a module and have it workable
>as P
hi Stas,
On Tue, Sep 11, 2012 at 12:23 AM, Stas Malyshev wrote:
> OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not
> everybody is going to upgrade to 5.5 soon, so having them participate
> would be good too. Maybe we could do it as a module and have it workable
> as PECL too
On Tue, Sep 11, 2012 at 7:47 AM, Stas Malyshev wrote:
> Hi!
>
>> We do not have this clue in master and there are for sure non
>> acceptable BC breaks in master. They won't be in 5.5. I'd said before,
>
> Why don't we have a clue? We definitely do have a clue, we have git logs
> and we know what w
Hi!
> We do not have this clue in master and there are for sure non
> acceptable BC breaks in master. They won't be in 5.5. I'd said before,
Why don't we have a clue? We definitely do have a clue, we have git logs
and we know what went into master - it is not that old. Could you list
the non-acce
hi,
On Mon, Sep 10, 2012 at 10:27 PM, Nikita Popov wrote:
> a) The current releaseprocess RFC [1] says that "Backward
> compatibility must be kept" in minor version increments (5.4 -> 5.5).
> Seeing the discussion above, may I rephrase this to "Only minor
> backwards compatibility breaks allowed"
On Tue, Sep 11, 2012 at 12:08 AM, Stas Malyshev wrote:
> Hi!
>
>> Based on our recent discussion on #pecl , I'd like we clarify what we
>> think is a "BCB" (Backward Compatibility Break) as well as what "only
>> minor BC breaks" could mean.
>> Stas' recent topic on internals "On BC and interfaces"
Hi!
> This is concerning me a bit. Does this mean that PHP 5.5 will be
> branched off PHP 5.4 and we will then backport features from master?
> If so, this would seem like a Very Bad Idea to me, from a purely
> technical point of view. Unless I'm much mistaken this would have to
I think also it's
Hi!
> Change in phpinfo related stuff are minor. Adding a notice or warning
> is minor or irrelevant. Changing return values (like suddenly
I'm not sure I agree about warning/notice. Depends if it's a clear bug -
either in our code (like, opening non-existing file produces warning but
opening it
Hi!
> Based on our recent discussion on #pecl , I'd like we clarify what we
> think is a "BCB" (Backward Compatibility Break) as well as what "only
> minor BC breaks" could mean.
> Stas' recent topic on internals "On BC and interfaces" may serve as a
> reflection basis.
> As our release process to
Hi!
> That's more about internals APIs, which is not what is meant in the
> release RFCs for x.y+1 releases.
The idea though wasn't about internals APIs. The idea was that for users
it's better to have platform that they can expect to work with their
code 10 years after than to have a platform th
Hi!
> The benefit is that it can be tested properly and bugs discovered and
> ironed out first.
> This is not the sort of thing you want to get security bug reports the
> day after its released in core.
> If your ego is big enough you can guarantee you have tested this
> thoroughly and want it to
On Mon, Sep 10, 2012 at 3:31 PM, Anthony Ferrara wrote:
> Hannes,
>
> On Sun, Sep 9, 2012 at 12:23 PM, Hannes Magnusson
> wrote:
>>
>> On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara
>> wrote:
>> > Hello all,
>> >
>> > I'm opening the vote for the simplified password hashing API indicated
>> > h
On Mon, Sep 10, 2012 at 9:54 PM, Rasmus Lerdorf wrote:
> On 09/10/2012 12:00 PM, Anthony Ferrara wrote:
>
>> I chose it for that specific reason. The line is blurry if taken literally
>> (which many do)...
>
> It can't possibly be an absolute rule. If you take it completely
> literally then we wou
On 09/10/2012 12:00 PM, Anthony Ferrara wrote:
> I chose it for that specific reason. The line is blurry if taken literally
> (which many do)...
It can't possibly be an absolute rule. If you take it completely
literally then we wouldn't be able to fix bugs either. Every change has
some effect tha
Pierre,
it does not break code, also that happens only and only from 5.x to
> 5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on
> very rare cases).
I agree it should not happen from 5.x.y to 5.x.y+1. But it definitely does
break code... Not all, but at least some...
>
> > I
hi,
On Mon, Sep 10, 2012 at 8:23 PM, Anthony Ferrara wrote:
> Pierre,
>
> On Mon, Sep 10, 2012 at 1:54 PM, Pierre Joye wrote:
>>
>> hi,
>>
>> On Mon, Sep 10, 2012 at 6:28 PM, jpauli wrote:
>> > Based on our recent discussion on #pecl , I'd like we clarify what we
>> > think is a "BCB" (Backward
Pierre,
On Mon, Sep 10, 2012 at 1:54 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Sep 10, 2012 at 6:28 PM, jpauli wrote:
> > Based on our recent discussion on #pecl , I'd like we clarify what we
> > think is a "BCB" (Backward Compatibility Break) as well as what "only
> > minor BC breaks" could mea
hi,
On Mon, Sep 10, 2012 at 6:28 PM, jpauli wrote:
> Based on our recent discussion on #pecl , I'd like we clarify what we
> think is a "BCB" (Backward Compatibility Break) as well as what "only
> minor BC breaks" could mean.
Change in phpinfo related stuff are minor. Adding a notice or warning
2012/9/10 jpauli :
> Based on our recent discussion on #pecl , I'd like we clarify what we
> think is a "BCB" (Backward Compatibility Break) as well as what "only
> minor BC breaks" could mean.
> Stas' recent topic on internals "On BC and interfaces" may serve as a
> reflection basis.
> As our rele
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a "BCB" (Backward Compatibility Break) as well as what "only
minor BC breaks" could mean.
Stas' recent topic on internals "On BC and interfaces" may serve as a
reflection basis.
As our release process told us that we sho
Hannes,
On Sun, Sep 9, 2012 at 12:23 PM, Hannes Magnusson <
hannes.magnus...@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara
> wrote:
> > Hello all,
> >
> > I'm opening the vote for the simplified password hashing API indicated
> here:
> >
> > https://wiki.php.net/rfc/passwor
On Thu, Mar 29, 2012 at 5:16 PM, Ferenc Kovacs wrote:
>
>
> On Thu, Mar 29, 2012 at 4:48 PM, Daniel Brown wrote:
>
>> On Thu, Mar 29, 2012 at 06:04, Ferenc Kovacs wrote:
>> >
>> > judging from the lack of interest I guess you are right.
>> > I will remove the cvs/cvsup subdomain from our zone f
Interesting technique:
http://ayende.com/blog/158721/rule-out-the-stupid-stuff-first-select-still-ainrsquo-t-broken
I wonder if this is applicable to PHP in any way? Would stream buffers
benefit from something like this?
Perhaps not, I just thought it was interesting enough to share - it's not a
23 matches
Mail list logo
