On Tue, 18 May 2004, Stanislav Malyshev wrote:
> Well, the big deal is that sometimes - probably, not this time, but
> sometimes - "small changes" break things that the author didn't even
> think about it in some entirely different place. And it's always
> unexpected and unforeseen. That's why ther
On Tuesday 18 May 2004 10:41, Stanislav Malyshev wrote:
> Well, the big deal is that sometimes - probably, not this time, but
> sometimes - "small changes" break things that the author didn't even
> think about it in some entirely different place.
Exactly. Case and point: loading of php extension
AZ>>Let me add to this: isn't this what "open source" is about? The bug
AZ>>did not manifest itself on my system (FreeBSD). You pointed out the
AZ>>issue. I fixed it. Cooperation prevailed. What's the big deal?
Well, the big deal is that sometimes - probably, not this time, but
sometimes - "small
George Schlossnagle wrote:
> Using 4.x as a guide, it's around 1 minor release per year.
Why not follow the good example of for instance the GNOME project?
They make 2 minor releases per year (with bugfix release in between) and
have a public release schedule / feature roadmap for each rele
It may be worth noting the way MySQL AB has been rolling out MySQL. They
released 4.0.0 as a restructured release, did bug fixes and small changes
up through 4.0.19, and are approaching the release of 4.1 with significant
new features. It sounds like the same might apply here.
~Jason
At 5/18/
On Tue, 18 May 2004, Andi Gutmans wrote:
> Thanks Andrei. I'm sorry about this mess (I know it's my fault).
> I think it's becoming clear things are being held back because of the 5.0
> release. As I mentioned I also have some work I'm holding back.
> I suggest so that we make sure that things are
Thanks Andrei. I'm sorry about this mess (I know it's my fault).
I think it's becoming clear things are being held back because of the 5.0
release. As I mentioned I also have some work I'm holding back.
I suggest so that we make sure that things aren't being held back for too
long we plan on rele
It's reverted. Hope everyone's happy.
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 17 May 2004, Sara Golemon wrote:
> Let me respond by saying there wasn't a big deal. I asked if this was too
> late in the RC cycle to justify a non-critical exception to the feature
> freeze. The response of "Andi/Zeev okayed it" was fine. But now you're
> standing there telling me that
On Mon, 17 May 2004, Ilia Alshanetsky wrote:
> Given the number of pending features various people want to add, perhaps now
> is the time for the 5.1 branch where all the new features can go to and if
> some prove to be stable and reliable. Then perhaps they can be introduced in
> 5.0.1, which w
On Mon, 17 May 2004, Andi Gutmans wrote:
> This is why I allowed important features in despite the feature freeze.
> However, it doesn't mean that unimportant stuff should go in as much as
> people want because otherwise we can't make a good release. I don't think
> open-source is about adding e
At 22:49 17/05/2004, George Schlossnagle wrote:
Using 4.x as a guide, it's around 1 minor release per year.
Waiting a month or two for a feature seems completely reasonable.
Waiting a year for it seems onerous.
4.x is completely irrelevant, because we only switched to the approach that
3rd digit r
Using 4.x as a guide, it's around 1 minor release per year.
Waiting a month or two for a feature seems completely reasonable.
Waiting a year for it seems onerous.
George
On May 17, 2004, at 3:41 PM, Zeev Suraski wrote:
I agree with everything Sara says.
So we delay it for a few months, what's th
I agree with everything Sara says.
So we delay it for a few months, what's the big deal there?
There are several features that we want to insert to PHP 5 but are not
because of the feature freeze (realpath cache, TSRM updates,
etc.). There'll be plenty of reasons to go for 5.1 pretty much immedi
But what separates an import feature from a slightly less important one? One
hand adding self contained function would not affect any of the code outside
of the function, so why not add it. That said, this function may introduce
new bugs and further delay the already much overdue release.
We may
This is why I allowed important features in despite the feature freeze.
However, it doesn't mean that unimportant stuff should go in as much as
people want because otherwise we can't make a good release. I don't think
open-source is about adding every single feature at any single point of
time.
> There is no such thing as a feature freeze in PHP land, historically.
> And that minor bug has already been fixed.
>
Oh what wonderful news, that means I can start commit patches again! Let's
see, I've got that source binding patch for the network stuff, I've got
those compression filters that I
Hey,
Definitely not a year. There are some features I'd like to work on right
after 5.0 but which I haven't done because of the feature freeze and the
possibility of affecting stability. I think if we open a 5.1 branch close
after releasing 5.0 we can probably release something within three mont
On Mon, 17 May 2004, Andrei Zmievski wrote:
> On Mon, 17 May 2004, Sara Golemon wrote:
> > Sure it's been inconsistently applied, but that doesn't mean that striving
> > for consistency is inherently bad. It's especially "not bad" when the
> > initial implementation of the exception in question is
On Mon, 17 May 2004, Sara Golemon wrote:
> Sure it's been inconsistently applied, but that doesn't mean that striving
> for consistency is inherently bad. It's especially "not bad" when the
> initial implementation of the exception in question is incompatable with one
> of the officially recommend
> > Personally, I'm +1 on this patch getting in PHP 5.0.0, as it is an
> > excellent
> > companion to the additional ini directory scan stuff.
>
> Feature freeze has always been highly inconsistently applied. There
> are plenty of functions added/augmented in point-releases of php4.
> This sudden
On May 17, 2004, at 1:08 PM, Wez Furlong wrote:
IMO, if we're going to be strict with the feature freeze, Andi/Zeev
should
have said no in the first place, rather than allowing it to be
committed and
then asking for it to be reverted.
Personally, I'm +1 on this patch getting in PHP 5.0.0, as it
tional ini directory scan stuff.
--Wez.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: 17 May 2004 17:46
> To: Andrei Zmievski
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Re: ZendEngine2 / zend_ini_parser.y
> zend_ini_sca
On Mon, 17 May 2004, Andrei Zmievski wrote:
> On Mon, 17 May 2004, Derick Rethans wrote:
> > I guess it would be around a year, and yes, that's a long time to wait
> > for a new feature.
>
> Whatever happened to "release early, release often" philosophy? I can't,
> no, I refuse to believe that we
On Mon, 17 May 2004, Derick Rethans wrote:
> I guess it would be around a year, and yes, that's a long time to wait
> for a new feature.
Whatever happened to "release early, release often" philosophy? I can't,
no, I refuse to believe that we have to wait another year to get a new
feature out.
- A
On Mon, 17 May 2004, Andrei Zmievski wrote:
> On Sun, 16 May 2004, Andi Gutmans wrote:
> > Yeah I think Zeev is probably right, especially as I don't think we need
> > more than one more RC before we release.
> > Andrei, do you mind if we revisit this after 5.0?
>
> How long will 5.1 take after 5.
On Sun, 16 May 2004, Andi Gutmans wrote:
> Yeah I think Zeev is probably right, especially as I don't think we need
> more than one more RC before we release.
> Andrei, do you mind if we revisit this after 5.0?
How long will 5.1 take after 5.0 is release? A month? A year?
- Andrei
--
PHP Inter
> > A) Isn't it late in the RC cycle to be adding features?
>
> I guess not. I got OK from Andi & Zeev.
>
I realized after sending that it sounded a bit hostile. I apologize for
that, but I was under the impression that we're into critical-only territory
at this point, and this feature is hardly c
Yeah I think Zeev is probably right, especially as I don't think we need
more than one more RC before we release.
Andrei, do you mind if we revisit this after 5.0?
Andi
At 12:00 PM 5/16/2004 +0300, Zeev Suraski wrote:
At 09:11 16/05/2004, Andi Gutmans wrote:
At 01:10 PM 5/15/2004 -0700, Sara Gole
At 09:11 16/05/2004, Andi Gutmans wrote:
At 01:10 PM 5/15/2004 -0700, Sara Golemon wrote:
A) Isn't it late in the RC cycle to be adding features?
Although personally I don't think this patch is very important/useful,
it's quite self-contained so we thought it'd wouldn't be a big deal to add it.
It
At 01:10 PM 5/15/2004 -0700, Sara Golemon wrote:
A) Isn't it late in the RC cycle to be adding features?
Although personally I don't think this patch is very important/useful, it's
quite self-contained so we thought it'd wouldn't be a big deal to add it.
It is kind of late and I do prefer not to a
On Sat, 15 May 2004, Sara Golemon wrote:
> A) Isn't it late in the RC cycle to be adding features?
I guess not. I got OK from Andi & Zeev.
> B) You're mising a ; (line 259)
Where exactly? What file? It compiles fine for me.
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To
I don't know, have you tried it?
-Andrei
> -Original Message-
> From: Christian Schneider [mailto:[EMAIL PROTECTED]
>
> Does this allow for VirtualHosts to use the global ini settings?
> E.g. could one do
> php_value include_path "/some/path:{$include_path}"
> with this patch?
>
> I thi
Sara Golemon wrote:
A) Isn't it late in the RC cycle to be adding features?
Does this allow for VirtualHosts to use the global ini settings?
E.g. could one do
php_value include_path "/some/path:{$include_path}"
with this patch?
I think this would be a very valuable addition.
- Chris
--
PHP Internal
A) Isn't it late in the RC cycle to be adding features?
B) You're mising a ; (line 259)
-Sara
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
Newsgroups: php.zend-engine.cvs
To: <[EMAIL PROTECTED]>
Sent: Friday, May 14, 2004 1:58 PM
Subject: cvs: ZendEngine2 / zend_in
35 matches
Mail list logo
