hi,
The release process RFC (https://wiki.php.net/rfc/releaseprocess)
voting phase is now closed.
The RFC has been approved.
PHP 5.4 will follow it for its development phase and releases.
How we adapt it to PHP 5.3 will be discussed later, especially its EOL.
Cheers,
--
Pierre
@pierrejoye |
On 06/28/2011 04:19 PM, Johannes Schlüter wrote:
On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote:
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)
I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty)
2011/6/29 Johannes Schlüter :
> On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote:
>> - Colours messages according to their response code (success=green,
>> client error=yellow, server error=red)
>
> I would prefer if this would be an ini option (if (cli_web_server.color
> && isatty) color = true)
On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote:
> - Colours messages according to their response code (success=green,
> client error=yellow, server error=red)
I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases
On Wed, Jun 29, 2011 at 12:37 AM, Arpad Ray wrote:
> Hi,
>
> This little patch makes the following changes to the CLI web server's
> console logging:
> - Compacts messages to one line, so a 404 doesn't occupy three lines.
> - Includes the response status code
> - Colours messages according to thei
Hi,
This little patch makes the following changes to the CLI web server's
console logging:
- Compacts messages to one line, so a 404 doesn't occupy three lines.
- Includes the response status code
- Colours messages according to their response code (success=green,
client error=yellow, server error
On Tue, 2011-06-28 at 22:51 +0100, Tim Streater wrote:
> On 28 Jun 2011 at 22:39, David Soria Parra wrote:
>
> > You can read more information about this release here:
> > http://www.php.net/archive/2011.php#id2011-06-28-1
>
> Not quite yet, perhaps?
will take a few minutes before it's up on ev
On 28 Jun 2011 at 22:39, David Soria Parra wrote:
> You can read more information about this release here:
> http://www.php.net/archive/2011.php#id2011-06-28-1
Not quite yet, perhaps?
--
Cheers -- Tim
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
Hello!
Stas has packed PHP 5.4.0alpha1 which you can find here:
http://downloads.php.net/stas/
Please test it carefully, and report any bugs in the bug system, but
only if you have a short reproducable test case. Alpha 2 will be
released in about 2 weeks.
You can read more information about
On Tue, Jun 28, 2011 at 10:06 PM, Hannes Magnusson
wrote:
> Hang on.. wait what?
> So Pierres weird threats on IRC weren't silly jokes?
>
> Heck, we could apt-get install bugzilla on a random mirror if you just
> want some bug tracker database to ignore and "have something".
Hannes, with all res
hi,
As you have noticed bugs.php.net has been down for almost two weeks
now. We are working on restoring the service completely within the
next couple of days.
In the mean time, https://bugs.php.net will be back online tonight
with the following restrictions:
- existing bugs (prior the disappear
> Hang on.. wait what?
> So Pierres weird threats on IRC weren't silly jokes?
>
> Heck, we could apt-get install bugzilla on a random mirror if you just
> want some bug tracker database to ignore and "have something".
>
merging the new bugs would be a little more work though.
and it would be weird
On Tue, Jun 28, 2011 at 21:59, Stas Malyshev wrote:
> Hi!
>
> On 6/28/11 12:49 PM, Hannes Magnusson wrote:
>>
>> On Tue, Jun 28, 2011 at 21:00, Stas Malyshev
>> wrote:
>>>
>>> final release. The point of alpha is not to provide a stable platform but
>>> initial point for the release and flush out
Hi!
On 6/28/11 12:49 PM, Hannes Magnusson wrote:
On Tue, Jun 28, 2011 at 21:00, Stas Malyshev wrote:
final release. The point of alpha is not to provide a stable platform but
initial point for the release and flush out bugs by expanding the user base.
It's not a production release.
Exactly.
On Tue, Jun 28, 2011 at 21:00, Stas Malyshev wrote:
> final release. The point of alpha is not to provide a stable platform but
> initial point for the release and flush out bugs by expanding the user base.
> It's not a production release.
Exactly. Requiring a working bug tracker.
Postponing the
On 06/28/2011 03:51 PM, Jarrod Nettles wrote:
> There are two projects that I've been following for awhile now: PLINQ
> and PHPLinq.
> http://plinq.codeplex.com/
> http://phplinq.codeplex.com/
> Both of them have made very solid attempts at providing LINQ-like
> functionality to PHP but with bo
Hi!
On 6/28/11 11:35 AM, Ferenc Kovacs wrote:
wasn't the alpha1 packaged in the last second?
it was packaged on Jun 19, and it was planned to be released on Jun 20.
and it did include obvious bugs.
No, it was not. It was checked, ensured it builds on all systems I have
access too, etc, and it
On Tue, Jun 28, 2011 at 8:25 PM, David Soria Parra wrote:
> On 2011-06-28, Stas Malyshev wrote:
>> Hi!
>>
>> On 6/28/11 10:43 AM, Pierre Joye wrote:
>>> I do think we should repackage. There are many issues fixed since last
>>> week and it makes no sense to release something not representing what
On 2011-06-28, Stas Malyshev wrote:
> Hi!
>
> On 6/28/11 10:43 AM, Pierre Joye wrote:
>> I do think we should repackage. There are many issues fixed since last
>> week and it makes no sense to release something not representing what
>> the current 5.4 branch is.
>
> Really, guys, if we ever want t
On June-28-11 2:06 PM Stas Malyshev wrote:
> On 6/28/11 10:43 AM, Pierre Joye wrote:
> > I do think we should repackage. There are many issues fixed since
> > last week and it makes no sense to release something not representing
> > what the current 5.4 branch is.
>
> Really, guys, if we ever wa
On Tue, Jun 28, 2011 at 8:06 PM, Stas Malyshev wrote:
> Hi!
>
> On 6/28/11 10:43 AM, Pierre Joye wrote:
>>
>> I do think we should repackage. There are many issues fixed since last
>> week and it makes no sense to release something not representing what
>> the current 5.4 branch is.
>
> Really, gu
Hi!
On 6/28/11 10:43 AM, Pierre Joye wrote:
I do think we should repackage. There are many issues fixed since last
week and it makes no sense to release something not representing what
the current 5.4 branch is.
Really, guys, if we ever want to have scheduled and orderly releases,
changing re
On 06/28/2011 10:43 AM, Pierre Joye wrote:
On Tue, Jun 28, 2011 at 7:31 PM, Stas Malyshev wrote:
We'll have alpha2 in a month. I'm really not a fan on last minute
repackaging, that's when screw ups happen almost every time.
I do think we should repackage. There are many issues fixed since
On Tue, Jun 28, 2011 at 7:31 PM, Stas Malyshev wrote:
> Hi!
>
>> Also, it's important to clarify that the [soon-to-be-popular]
>> built-in web server is not part of this alpha because the alpha was
>> tagged a few days before its addition. I think repackaging would be
>> worth it for this case, bu
Hi!
Also, it's important to clarify that the [soon-to-be-popular]
built-in web server is not part of this alpha because the alpha was
tagged a few days before its addition. I think repackaging would be
worth it for this case, but waiting for alpha2 is feasible.
We'll have alpha2 in a month. I'
On Jun 28, 2011, at 9:57 AM, Stas Malyshev wrote:
> Hi!
>
> On 6/28/11 9:55 AM, Derick Rethans wrote:
>> On Tue, 28 Jun 2011, Stas Malyshev wrote:
>>
>> I'm actually surprised it isn't in there. I did write that document
>> some eons ago. But anyway, let's add it then :)
>
> OK, as soon as we
Hi!
On 6/28/11 9:55 AM, Derick Rethans wrote:
On Tue, 28 Jun 2011, Stas Malyshev wrote:
I'm actually surprised it isn't in there. I did write that document
some eons ago. But anyway, let's add it then :)
OK, as soon as we are all agreed on Thursday and it's there I'll shift
the schedule for
hi,
On Tue, Jun 28, 2011 at 6:54 PM, Hannes Magnusson
wrote:
> Little preference?
>
> According http://www.php.net/releases/
>
>
> array(4) {
> ["Thursday"]=>
> int(30)
> ["Tuesday"]=>
> int(3)
> ["Monday"]=>
> int(3)
> ["Wednesday"]=>
> int(1)
> }
So Thursday was the big preference, we
On Tue, 28 Jun 2011, Stas Malyshev wrote:
> > I would also like to point out that Thursday is our general release day,
> > and we have a release process described in detail here:
> > http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
>
> It doesn't say
On Tue, Jun 28, 2011 at 18:45, Pierre Joye wrote:
> On Tue, Jun 28, 2011 at 6:39 PM, Stas Malyshev wrote:
>
>>> I would also like to point out that Thursday is our general release day,
>>> and we have a release process described in detail here:
>>>
>>> http://svn.php.net/viewvc/php/php-src/trunk/
On Tue, Jun 28, 2011 at 6:39 PM, Stas Malyshev wrote:
>> I would also like to point out that Thursday is our general release day,
>> and we have a release process described in detail here:
>>
>> http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
>
> It
Hi!
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:
http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614&view=markup
It doesn't say there Thursday is our general release day. If we wa
There are two projects that I've been following for awhile now: PLINQ
and PHPLinq.
http://plinq.codeplex.com/
http://phplinq.codeplex.com/
Both of them have made very solid attempts at providing LINQ-like
functionality to PHP but with both, I've been a little frustrated
with the implementations
2011/6/28 David Zülke :
> On 28.06.2011, at 14:26, Johannes Schlüter wrote:
>
>> On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote:
>>
>>> On 27.06.2011, at 01:55, Stas Malyshev wrote:
>>>
However, it still has a chance somebody's data won't work after the
update if he had 8-bit data h
On 28.06.2011, at 14:26, Johannes Schlüter wrote:
> On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote:
>
>> On 27.06.2011, at 01:55, Stas Malyshev wrote:
>>
>>> However, it still has a chance somebody's data won't work after the
>>> update if he had 8-bit data hashed with old crypt(). He woul
On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote:
> On 27.06.2011, at 01:55, Stas Malyshev wrote:
>
> > However, it still has a chance somebody's data won't work after the
> update if he had 8-bit data hashed with old crypt(). He would need
> either to re-hash or to change prefix from $2a to $
On Mon, 20 Jun 2011, Stas Malyshev wrote:
> Since we've got voting on the process RFCs finally going on, after much
> deliberation we've decided it'd be best to let the votes finish before the
> first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1 until
> June 28th (next Tuesday).
On 28 June 2011 18:08, Dave Ingram wrote:
> So what about modifying the loop syntax slightly, to explicitly scope a
> variable in a foreach? Or would this be problematic/counter-intuitive too?
>
> foreach ($abc as var $def) {
> }
>
> and
>
> foreach ($abc as var &$def) {
> }
PHP's scoping behavio
On 27.06.2011, at 01:55, Stas Malyshev wrote:
> However, it still has a chance somebody's data won't work after the update if
> he had 8-bit data hashed with old crypt(). He would need either to re-hash or
> to change prefix from $2a to $2x.
IMO that's a fair trade-off; people could even implem
On 06/23/11 21:48, John Crenshaw wrote:
>> I think proposed change is extremely counter intuitive to the design
>> of PHP in regard to scoping and would be a very large bc break, PHP is
>> doing exactly what it is suppose to do here and I wouldn't want it any
>> other way.
> Agreed. Although I gene
40 matches
Mail list logo
