On Fri, 19 Mar 2010, la...@garfieldtech.com wrote:
> The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders
> or hosters. Sure it's mostly compatible, and you certainly can write code
> that works from 5.0->5.3 just fine, and if not then you're probably doing
> something wr
On 3/19/10 10:34 AM, Eric Stewart wrote:
When significant releases are 2-3 years apart, web hosts can expect to
have to
put in actual work every couple of years and mass-market developers can
expect
to have to beat their hosts over the head with a stick every few years.
If
significant re
On Fri, Mar 19, 2010 at 11:12 AM, Nate Gordon wrote:
> On Fri, Mar 19, 2010 at 3:31 AM, Ferenc Kovacs wrote:
>
> > On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield
> > wrote:
> > > On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
> > >
> > >> +1 For shorter release cycles. Shorter relea
On Fri, Mar 19, 2010 at 3:31 AM, Ferenc Kovacs wrote:
> On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield
> wrote:
> > On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
> >
> >> +1 For shorter release cycles. Shorter release cycles could also allow
> us
> >> to move major releases immedia
On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield wrote:
> On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
>
>> +1 For shorter release cycles. Shorter release cycles could also allow us
>> to move major releases immediately to bug and security fixes only. I've
>> never been a fan of seei
On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
> +1 For shorter release cycles. Shorter release cycles could also allow us
> to move major releases immediately to bug and security fixes only. I've
> never been a fan of seeing additional features added in minor releases.
> It's confus
On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith wrote:
>
> On 18.03.2010, at 18:48, David Soria Parra wrote:
>
> On 2010-03-18, Pierre Joye wrote:
>>
>>> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>>>
>>> I do agree that we need to do major releases more often, but just
se
On 18.03.2010, at 18:48, David Soria Parra wrote:
On 2010-03-18, Pierre Joye wrote:
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans
wrote:
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it
I propose that sort of a
unicode working group forms but much less formal than what I make it
sound like. I think the discussions can remain on internals@ and
hopefully alternative approaches will be documented as RFCs. But what
I mean with working group is a list of a handful of names who feel
On 2010-03-18, Pierre Joye wrote:
> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>
>> I do agree that we need to do major releases more often, but just
>> setting a time already feels wrong. It's still open source, so it's
>> ready when it is ready. That of course should not mean that w
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>> As for unicode, I would like the next release to be planned
>> independently of finding a solution for unicode, but with the clear
>> option that it will be included if we find a good solution in time
>> (like I said I think it would be go
On Tue, 16 Mar 2010, Lukas Kahwe Smith wrote:
> On 16.03.2010, at 16:58, Derick Rethans wrote:
>
> other stuff:
> http://wiki.php.net/todo/php60
> http://wiki.php.net/todo/backlog
yeah, I know there is other stuff, I was just listing a few examples of
things I remembered. Both lists require som
On Thu, Mar 18, 2010 at 5:46 PM, Derick Rethans wrote:
> On Tue, 16 Mar 2010, Zeev Suraski wrote:
>
>> At 17:58 16/03/2010, Derick Rethans wrote:
>> > - Declare 5.2 security fixes only (Something for Ilia to declare).
>> > - Declare 5.3 bug fixes only (and ini-mini features if so desired)
>> > (
On Tue, 16 Mar 2010, Zeev Suraski wrote:
> At 17:58 16/03/2010, Derick Rethans wrote:
> > - Declare 5.2 security fixes only (Something for Ilia to declare).
> > - Declare 5.3 bug fixes only (and ini-mini features if so desired)
> > (Something for Johannes to declare).
> >
> > Once that's done, I
On Wed, 17 Mar 2010, Antony Dovgal wrote:
> On 03/16/2010 07:13 PM, Derick Rethans wrote:
> >> + merge php-fpm branch?
> >
> > Can't see why not. Is there an RFC for this?
>
> No, there are no RFCs on that.
> Just copy sapi/fpm to 5_4 and you've merged it.
There is no 5_4, but still, I think th
> -Original Message-
> From: Antony Dovgal [mailto:t...@daylessday.org]
> Sent: Wednesday, March 17, 2010 2:25 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
>
> On 03/16/2010 07:13 PM, Derick Rethans wrote:
> >> + merge
On Tue, Mar 16, 2010 at 22:12, Lukas Kahwe Smith wrote:
>
> On 16.03.2010, at 19:23, Hannes Magnusson wrote:
>
>> You didn't even list the mbstring patch.. that was discussed and as
>> far as I remember everyone thought it was great idea, just not in a
>> stable branch.
>
>
> Is this tone really n
On Tue, 16 Mar 2010, Stanislav Malyshev wrote:
> > Does that mean you want to take up a
> > - strict RFC-and-after-3months-discussion-before-commit policy
> >(i.e. killing the scratching-an-itch spirit of PHP)
> > - "I'm going to commit this patch tomorrow" mail to internals@
> >(i.e.
On Wed, Mar 17, 2010 at 10:25 AM, Antony Dovgal wrote:
> On 03/16/2010 07:13 PM, Derick Rethans wrote:
>>> + merge php-fpm branch?
>>
>> Can't see why not. Is there an RFC for this?
>
> No, there are no RFCs on that.
> Just copy sapi/fpm to 5_4 and you've merged it.
There is no 5.4 either, trunk
On 03/16/2010 07:13 PM, Derick Rethans wrote:
>> + merge php-fpm branch?
>
> Can't see why not. Is there an RFC for this?
No, there are no RFCs on that.
Just copy sapi/fpm to 5_4 and you've merged it.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals -
On 17 March 2010 16:50, Jan Schneider wrote:
> How about 5.3.99? A lot of projects use this for pre-releases, but it still
> might make sense.
I'm wary of sticking with anything starting with 5.3 if we're going to
break binary compatibility on the new trunk (which we presumably are)
— it undermin
Zitat von Johannes Schlüter :
On Tue, 2010-03-16 at 22:13 +0100, Lukas Kahwe Smith wrote:
On 16.03.2010, at 16:58, Derick Rethans wrote:
> Before we add features, they need to be discussed whether we want to
> have them. As version name for it I would like to use "trunk-dev" (and
> not 5.4-dev
On Tue, 2010-03-16 at 22:13 +0100, Lukas Kahwe Smith wrote:
> On 16.03.2010, at 16:58, Derick Rethans wrote:
>
> > Before we add features, they need to be discussed whether we want to
> > have them. As version name for it I would like to use "trunk-dev" (and
> > not 5.4-dev or 6.0-dev) as we're
On 16.03.2010, at 16:58, Derick Rethans wrote:
> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
Eventually it should be deleted, if it helps at all in merging the OB change
then it should be kept until that happens, otherwise it can be deleted now
imho. The new 5.3 based
On 16.03.2010, at 16:58, Derick Rethans wrote:
> Before we add features, they need to be discussed whether we want to
> have them. As version name for it I would like to use "trunk-dev" (and
> not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving.
> Right now, there are the foll
On 16.03.2010, at 19:23, Hannes Magnusson wrote:
> On Tue, Mar 16, 2010 at 16:58, Derick Rethans wrote:
>> Before we add features, they need to be discussed whether we want to
>> have them.
>
> Does that mean you want to take up a
> - strict RFC-and-after-3months-discussion-before-commit policy
Hi!
Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP)
- "I'm going to commit this patch tomorrow" mail to internals@
(i.e. killing "I need this functionality, maybe others do to" spiri
On 03/16/2010 11:00 PM, Johannes Schlüter wrote:
> On Tue, 2010-03-16 at 19:11 +0300, Alexey Zakhlestin wrote:
>> + merge php-fpm branch?
>
> If we get a trunk which will be released in a foreseeable timeframe we
> don't need to merge this to 5.3 anymore, which had been an old plan.
> Tony, do you
On Tue, 2010-03-16 at 19:11 +0300, Alexey Zakhlestin wrote:
> + merge php-fpm branch?
If we get a trunk which will be released in a foreseeable timeframe we
don't need to merge this to 5.3 anymore, which had been an old plan.
Tony, do you agree?
johannes
--
PHP Internals - PHP Runtime Developm
On Tue, Mar 16, 2010 at 16:58, Derick Rethans wrote:
> Before we add features, they need to be discussed whether we want to
> have them.
Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP)
- "I
On Tue, Mar 16, 2010 at 17:54, Pierre Joye wrote:
> On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann
> wrote:
>> Am 16.03.2010 16:58, schrieb Derick Rethans:
>>> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
>>> trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
>>
>> Why
On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann
wrote:
> Am 16.03.2010 16:58, schrieb Derick Rethans:
>> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
>> trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
>
> Why do we need THE_5_4_THAT_ISNT_5_4
Right, this branch must b
Am 16.03.2010 16:58, schrieb Derick Rethans:
> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
> trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
Why do we need THE_5_4_THAT_ISNT_5_4 and trunk? trunk should be where
the development happens. When the time comes for a release
On Tue, 16 Mar 2010, Alexey Zakhlestin wrote:
> On Tue, Mar 16, 2010 at 6:58 PM, Derick Rethans
> wrote:
>
> > Right now, there are the following features that I can see we should
> > think about:
> >
> > - the new output buffering mechanism (I can not really see why we would
> > not want this
On Tue, Mar 16, 2010 at 6:58 PM, Derick Rethans wrote:
> Right now, there are the following features that I can see we should
> think about:
>
> - the new output buffering mechanism (I can not really see why we would
> not want this)
> - Scott's big number improvements. Scott, can you explain (i
35 matches
Mail list logo
