On Tue, Jun 6, 2017 at 12:52 AM, Remi Collet wrote:
> Le 30/05/2017 à 06:27, Sara Golemon a écrit :
>> https://wiki.php.net/rfc/release-md5-deprecation
>>
>> Primary discussion points: Deprecate or Remove? Deprecate for how long?
>>
>
> +1 for dropping md5 checksums for 7.2 releases
>
> And I don'
Le 30/05/2017 à 06:27, Sara Golemon a écrit :
> https://wiki.php.net/rfc/release-md5-deprecation
>
> Primary discussion points: Deprecate or Remove? Deprecate for how long?
>
+1 for dropping md5 checksums for 7.2 releases
And I don't think adding sha256 for old releases (which are unsecure)
wor
https://wiki.php.net/rfc/release-md5-deprecation
Primary discussion points: Deprecate or Remove? Deprecate for how long?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
* Christian Kaps wrote:
> Since ebuild php-5.3.3 Gentoo introduced a set of new features. One of
> them is the PHP_INI_VERSION variable in the file /etc/make.conf. If you
> don't set this variable, Gentoo installs the development version of the
> php.ini file. I think this is your problem. For mo
On 1/2/11 11:56 PM, Christian Kaps wrote:
> Am 03.01.2011 02:41, schrieb Enrico Weigelt:
>
>>>
>>> No, as usual on Gentoo, config files are never overwritten, but
>>> written to another place and tools like etc-update show you the
>>> differences. I've merged the configs manually, and I'm pretty
>
On 01/03/2011 02:23 PM, Reindl Harald wrote:
>> Hence a new /etc/php layout, hence the need to migrate your
>> config.
>
> Hm, i am not a gentoo user but this is not so fine as long most users
> have installed only one php-version
Yeah, right now talking about having a symlink to the active confi
Am 03.01.2011 14:00, schrieb Matti Bickel:
> On 01/03/2011 08:56 AM, Christian Kaps wrote:
>> Since ebuild php-5.3.3 Gentoo introduced a set of new features.
>
> Which includes the possibility to have each minor version of PHP
> installed in parallel.
Sounds nice
> Hence a new /etc/php layout,
On 01/03/2011 08:56 AM, Christian Kaps wrote:
> Since ebuild php-5.3.3 Gentoo introduced a set of new features.
Which includes the possibility to have each minor version of PHP
installed in parallel. Hence a new /etc/php layout, hence the need to
migrate your config. Which I foolishly assumed user
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> >
> > No, as usual on Gentoo, config files are never overwritten, but
> > written to another place and tools like etc-update show you the
> > differences. I've merged the configs manually, and I'm pretty
> > sure I didn't add anything like error_repor
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> * Rasmus Lerdorf wrote:
>
>> Also, you said this happened between 5.3.2 and 5.3.3? Looking through
>> the diff between those two versions we did not add any new deprecation
>> warnings. We tend to not do that in a minor release. At least I don't
>>
Am 03.01.2011 02:19, schrieb Enrico Weigelt:
> In essence you say here, that I should diff the production config
> example from one version to another to find out what changed
> and adapt my config, on each update.
Hm thats your job as sysadmin
> Adds about 15mins extra work
What is your job
>
Hi!
In essence you say here, that I should diff the production config
example from one version to another to find out what changed
No. You should use it now and should always have used it. There was no
change in this config parameter at least since 5.3.0. Look in the public
SVN repo if you d
Hi!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed ? ;-o)
No, it has not. Whatever "magically changed" on your system was not
caused by PHP. On the other hand it gave you a chance to fix a serious
configuration problem on your server,
On 1/2/11 5:45 PM, Enrico Weigelt wrote:
> * Rasmus Lerdorf wrote:
>
>> Nope, we really didn't change anything. The simple explanation is
>> that you installed without or with a different php.ini from the
>> previous version.
>
> Of course, I've kept my original (old) config and just adapted
>
* Rasmus Lerdorf wrote:
> Nope, we really didn't change anything. The simple explanation is
> that you installed without or with a different php.ini from the
> previous version.
Of course, I've kept my original (old) config and just adapted
some things to the new default config manually. So it
* Rasmus Lerdorf wrote:
> Also, you said this happened between 5.3.2 and 5.3.3? Looking through
> the diff between those two versions we did not add any new deprecation
> warnings. We tend to not do that in a minor release. At least I don't
> recall the last time we did so.
That's where I not
On Mon, 03 Jan 2011 01:14:42 -, Enrico Weigelt
wrote:
* Stas Malyshev wrote:
Of course, nobody personally has any time. But PHP is a volunteer
project, so if nobody has the time, nobody should complain about "php
developers not caring". PHP developers are caring, but it's not humanly
p
On 1/2/11 5:14 PM, Enrico Weigelt wrote:
> * Stas Malyshev wrote:
>> Hi!
>>
>>> IIRC many deprecation warnings, which totally broke the output.
>>
>> Err, you actually output the warnings in your output? In production?!
>
> Something seem to turn them on magically, no idea what it was.
> (perhap
* Stas Malyshev wrote:
> Hi!
>
> >Unfortunately, yes. I didn't enable that - happend magically
> >on the update. That's yet another strange point here - why do
> >such warnings go stdout per default, instead of syslog ? ;-o
>
> You should use settings based on php.ini-production in production. O
* Stas Malyshev wrote:
> Hi!
>
> >IIRC many deprecation warnings, which totally broke the output.
>
> Err, you actually output the warnings in your output? In production?!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed ? ;-o)
> >I, per
On 1/2/11 4:52 PM, Enrico Weigelt wrote:
> * Rasmus Lerdorf wrote:
>
>> Your application broke because of a deprecation warning? Are you
>> sending PHP errors to the user in your production code?
>
> Unfortunately, yes. I didn't enable that - happend magically
> on the update. That's yet anot
* James Butler wrote:
> As a 'grown up' you should never expect changes to a system
> to just work without testing, any change introduces risk,
> you need to mitigate against that risk by testing.
True, but applications should be designed in a way that minimizes
the risk of breaks.
> Irrespect
Hi!
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdout per default, instead of syslog ? ;-o
You should use settings based on php.ini-production in production. One
of these is display_errors=Off. Us
* Rasmus Lerdorf wrote:
> Your application broke because of a deprecation warning? Are you
> sending PHP errors to the user in your production code?
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdo
Hi!
IIRC many deprecation warnings, which totally broke the output.
Err, you actually output the warnings in your output? In production?!
Please tell me you turned it off now, at least - it would make
deprecation warning doubly beneficial. I'd even consider inserting
couple of random ones j
As a 'grown up' you should never expect changes to a system to just work
without testing, any change introduces risk, you need to mitigate against that
risk by testing. Irrespective of whatever the php release notes say (you did
read them didn't you), one should run the new version against your
On 12/31/10 3:49 AM, Enrico Weigelt wrote:
> * Stas Malyshev wrote:
>> Hi!
>>
>>> Just had such a problem myself a few weeks ago: a minor update
>>> (IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications
>>
>> Out of curiosity - what exactly broke it? What change was it?
>
> II
* Stas Malyshev wrote:
> Hi!
>
> >Just had such a problem myself a few weeks ago: a minor update
> >(IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications
>
> Out of curiosity - what exactly broke it? What change was it?
IIRC many deprecation warnings, which totally broke the
2010/12/31 Ferenc Kovacs :
> On Fri, Dec 31, 2010 at 6:25 AM, Stas Malyshev wrote:
[snip]
> Btw: maybe we could announce the RCs to a wider audience.
> I mean announce it on the site, tweet/blog about it, ask the community for
> testing and feedback.
> currently only thoose who closely follow the
On Fri, Dec 31, 2010 at 6:25 AM, Stas Malyshev wrote:
> Hi!
>
>
> Just had such a problem myself a few weeks ago: a minor update
>> (IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications
>>
>
> Out of curiosity - what exactly broke it? What change was it?
>
>
> I got the stran
Hi!
Just had such a problem myself a few weeks ago: a minor update
(IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications
Out of curiosity - what exactly broke it? What change was it?
I got the strange feeling that php-devs don't care very much of long
term stability ;-p
* James Butler wrote:
> Enterprise (who-ever that is :-) now uses PHP and as such will
> want PHP to have some degree of uniformity with release cycles
> and feature addition/removal so that they can easily factor it
> in to their own deployment/upgrade plans etc.
Having worked for several lar
* Ferenc Kovacs wrote:
> You can't expect the users to switch to the new major version as soon as it
> comes out. They have to either migrate their codebase, and sadly they will
> wait(at least me and my collegues/friends do this) one or two micro/build
> version bump, usually the new major/major
On Mon, 22 Nov 2010, Felipe Pena wrote:
> [1] http://wiki.php.net/rfc/releaseprocess
Now I've thought a bit more about it, I'm trying to reply to this with
some constructive comments. I'm reordering it a bit in the response
where it makes sense to do. In a general way, some of the things in here
hi Andi,
On Thu, Nov 25, 2010 at 7:42 AM, Andi Gutmans wrote:
> I agree with that. More structure and predictability will be very valuable to
> the project. We created a lot of structure in Zend Framework and it has
> really paid off.
> Btw, we don't have to look far. Just the change in having
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Wednesday, November 24, 2010 9:39 PM
> To: Derick Rethans
> Cc: Felipe Pena; internals
> Subject: Re: [PHP-DEV] [RFC] Release Process
>
> Hi!
>
> >> With the recent
Hi!
With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]
Really? I think you're blowing this all way out of proportion.
I don't mind a yearly release cycle, as we should get out more releases.
I don
hi,
amen.
On Tue, Nov 23, 2010 at 3:17 PM, Matthew Weier O'Phinney
wrote:
> On 2010-11-23, Derick Rethans wrote:
>> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>> > > All the rest you write in the RFC is basically already as we do it.
>> >
>> > yeah, maybe, but they aren't written down, accepted
hi,
2010/11/23 Ilia Alshanetsky :
> I think support 5 or even 3 parallel versions will be highly
> impractical and extra-ordinarily challenging. I think we need a plan
> that limits us to 2 versions and perhaps a 3rd one for critical
> security fixes only.
Yes, that's what the two examples tried
2010/11/23 Ilia Alshanetsky
> I think support 5 or even 3 parallel versions will be highly
> impractical and extra-ordinarily challenging. I think we need a plan
> that limits us to 2 versions and perhaps a 3rd one for critical
> security fixes only.
>
> 2010/11/23 Johannes Schlüter :
> > Hi,
> >
I think support 5 or even 3 parallel versions will be highly
impractical and extra-ordinarily challenging. I think we need a plan
that limits us to 2 versions and perhaps a 3rd one for critical
security fixes only.
2010/11/23 Johannes Schlüter :
> Hi,
>
> On Mon, 2010-11-22 at 23:21 -0200, Felipe
On Tue, Nov 23, 2010 at 3:58 PM, Derick Rethans wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans wrote:
> >
> > > On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > >
> > > > > All the rest you write in the RFC is basically already as we do it.
On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans wrote:
>
> > On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> >
> > > > All the rest you write in the RFC is basically already as we do it.
> > >
> > > yeah, maybe, but they aren't written down, accepted and w
On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
> The status quo works great for those whom it serves. For everyone else,
> it stinks. There's no transparency, which leads to disenfranchisement.
That's why my first reply said:
I don't mind a yearly release cycle, as we should get out more r
-Original Message-
From: Matthew Weier O'Phinney [mailto:weierophin...@php.net]
Sent: 23 November 2010 14:18
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Release Process
On 2010-11-23, Derick Rethans wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > >
t: Re: [PHP-DEV] [RFC] Release Process
On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down
On 2010-11-23, Derick Rethans wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules, so
> > you can forgot/misunderstand/bend them. :/
>
> And I
On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans wrote:
> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > > All the rest you write in the RFC is basically already as we do it.
> >
> > yeah, maybe, but they aren't written down, accepted and well-known rules,
> so
> > you can forgot/misunderstand/be
On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > All the rest you write in the RFC is basically already as we do it.
>
> yeah, maybe, but they aren't written down, accepted and well-known rules, so
> you can forgot/misunderstand/bend them. :/
And I don't think that is a bad thing. It's good to be a
On Tue, Nov 23, 2010 at 11:07 AM, Derick Rethans wrote:
> On Mon, 22 Nov 2010, Felipe Pena wrote:
>
> > With the recent chaos in the way we begin and ended releases, we would
> > like to propose a clean way to deal with releases and related decisions:
> [1]
>
> Really? I think you're blowing this
On Mon, 22 Nov 2010, Felipe Pena wrote:
> With the recent chaos in the way we begin and ended releases, we would
> like to propose a clean way to deal with releases and related decisions: [1]
Really? I think you're blowing this all way out of proportion.
I don't mind a yearly release cycle, as
Hi,
On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote:
> With the recent chaos in the way we begin and ended releases, we would
> like to propose a clean way to deal with releases and related decisions: [1]
Thanks for preparing this. I have one change proposal:
With the proposed model it migh
Hi,
With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]
PHP releases have always been done spontaneously, in a somehow chaotic
way. Individual(s) decided when a release will happen and what could
or co
53 matches
Mail list logo
