Hi Steph:
On Wed, Feb 11, 2009 at 07:02:35PM -, Steph Fox wrote:
>
> In the last two upgrading guides, we've repeated much of what is already
> in the NEWS file or in the release notes. This makes me wonder what the
> point is of having an upgrading guide...?
Because the guide is in the man
Hey Steph,
Personally I think we should list all changes. For certain changes we
should devote some explanations (like E_DEPRECATED). For the most part
I see this document as a place where we provide an overview of things
which then gives them the right key word to look in the documentation
Hi all,
Please find a patch attached which makes it possible to have secure
suexec CGI / FastCGI PHP scripts without using safe_mode (note that this
configuration is currently widely used, for example by shared web hosts,
but there is no way to make it secure with an unpatched PHP version).
For
On Wed, Feb 11, 2009 at 20:55, Steph Fox wrote:
> Please go back to the original discussion about the purpose of this guide.
> It was aimed primarily at sysadmins. If we turn it into a prettier version
Then I guess I need to read the archives.
I can't imagine why a system admin would give a damn
Hi.
On 11.02.2009 15:26 Uhr, Christian Schneider wrote:
session.bug_compat_42 = Off ; Why should devel/production differ?
Because in dev a warning should be shown, but the warning setting only
has an effect if this setting is on (at least that way it is documented
in php.ini).
Regards,
Kar
An upgrade is not only about problems, it is also about solutions.
You need a problem before providing a solution. Really.
A
kind of tutorial on how to use all the changes in a given release in
your applications. It often helps to clean codes, remove work 'round,
etc. An upgrade guide is often
On Wed, Feb 11, 2009 at 8:44 PM, Steph Fox wrote:
>> IMHO listing new functions is useful - there could be a name collision
>> with
>> a function in users code (I know it is improbable, because the functions
>> are
>> named extname_funcname, but still possible)
>
> Improbable indeed. The nearest w
IMHO listing new functions is useful - there could be a name collision
with
a function in users code (I know it is improbable, because the functions
are
named extname_funcname, but still possible)
Improbable indeed. The nearest we ever came to that was with the Date class
(because PEAR alread
IMHO listing new functions is useful - there could be a name collision with
a function in users code (I know it is improbable, because the functions are
named extname_funcname, but still possible)
On Wed, Feb 11, 2009 at 9:26 PM, Steph Fox wrote:
>
> But this was actually an add-on after I put
But this was actually an add-on after I put the initial 5.1 upgrading
guide
together. A 200-line document became a 500-line document overnight, and
voila - nobody reads the thing.
Actually I'm wrong - that was 5.2. The 5.1 upgrade guide appears to be
as-was.
So again, why are we listing ne
Hi Hannes,
Think about the online manual. In 2 years from now people should still
be able to read the upgrading guide and it should still make sense
without needing to hunt down random release announcements or outdated
NEWS files.
The upgrade which gets committed to php-src will be taken, word
On Wed, Feb 11, 2009 at 20:02, Steph Fox wrote:
> In the last two upgrading guides, we've repeated much of what is already in
> the NEWS file or in the release notes. This makes me wonder what the point
> is of having an upgrading guide...?
Think about the online manual. In 2 years from now peopl
Hi Lukas, all,
'Scuse top-posting, no >>> history marks here.
It's not actually 'open' so much as 'under way' - the file's in place and
has content, it just needs some thought applying to it.
In the last two upgrading guides, we've repeated much of what is already in
the NEWS file or in the
Hi,
> variables_order: They should be the same on dev and prod.
>
> request_order: Seems like it should be the same.
Caution! I've read several times in this thread that request_order
should be set to something that also contains C. This is DANGEROUS.
request_order was specifically introduced
Hi
2009/2/11 Guilherme Blanco :
> Hey,
>
> IMHO dev environment should be E_ALL | E_STRICT | E_DEPRECATED
E_DEPRECATED is apart of E_ALL (like Lukas just said), so I'd say:
; Development
error_reporting = E_ALL | E_STRICT (5.3)
error_reporting = E_ALL (6.0+)
; Production
error_reporting = E_ALL
Hi,
It seems aside from some smaller commits, the last minute closure
change has gone through without issues.
Our todo list however doesnt have that many checked off items:
http://wiki.php.net/todo/php53#next_release_beta2rc1
To me the biggest issue is the UPGRADING README. So please approach
On 11.02.2009, at 17:19, Ilia Alshanetsky wrote:
On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote:
Hi Eric:
On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote:
http://wiki.php.net/rfc/newinis
Thanks for the work.
I noticed the actual directives in the files are the same. I g
Hey,
IMHO dev environment should be E_ALL | E_STRICT | E_DEPRECATED
Regards,
On Wed, Feb 11, 2009 at 2:19 PM, Ilia Alshanetsky wrote:
>
> On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote:
>
>> Hi Eric:
>>
>> On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote:
>>>
>>> http://wiki.php.
On 11-Feb-09, at 11:11 AM, Daniel Convissor wrote:
Hi Eric:
On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote:
http://wiki.php.net/rfc/newinis
Thanks for the work.
I noticed the actual directives in the files are the same. I guess
you
just focused on the Quick Reference secti
Hi Eric:
On Mon, Feb 09, 2009 at 09:27:03PM -0500, Eric Stewart wrote:
> http://wiki.php.net/rfc/newinis
Thanks for the work.
I noticed the actual directives in the files are the same. I guess you
just focused on the Quick Reference section and getting the comments set
up the way you want.
L
2009/2/11 Ilia Alshanetsky :
>
> On 11-Feb-09, at 9:26 AM, Christian Schneider wrote:
>
>> Eric Stewart wrote:
>>>
>>> A new RFC for PHP's proposed INI files have been added to the wiki. Below
>>> is
>>> a direct link to the page.
>>> http://wiki.php.net/rfc/newinis
>>
>> Good work IMHO.
>>
>> Simi
On 11-Feb-09, at 9:26 AM, Christian Schneider wrote:
Eric Stewart wrote:
A new RFC for PHP's proposed INI files have been added to the wiki.
Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis
Good work IMHO.
Similar to what Karsten Dambekalns wrote I think we should only
Eric Stewart wrote:
> A new RFC for PHP's proposed INI files have been added to the wiki. Below is
> a direct link to the page.
> http://wiki.php.net/rfc/newinis
Good work IMHO.
Similar to what Karsten Dambekalns wrote I think we should only have a
difference between devel and production for disp
Hi,
last weekend at FOSDEM in Brussels Leslie Hawthorn announced this year's
Google Summer of Code program. Meanwhile the FAQ including the timeline
has been published.
http://code.google.com/opensource/gsoc/2009/faqs.html
According to that participating organizations are published on March 18.
Am 10.02.2009 um 03:27 schrieb Eric Stewart:
A new RFC for PHP's proposed INI files have been added to the wiki.
Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis
For -development, display_errors should *definitely* be on, and
error_reporting should be E_ALL | E_STRICT.
25 matches
Mail list logo
