Re: [PHP-DEV] Re: ; arg seperator
[Jani Taskinen [EMAIL PROTECTED]] (could we have some nice 'codenames' for the releases? Please.. :) Hey, what if we name them after the third noun on page five of your (finnish) morning paper at the day of RC1 (using GMT)? :-) - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
Quoting Hartmut Holzgraefe [EMAIL PROTECTED]: arg_separator.output should default to 'nbsp;'. nbsp; ??? i guess it will break lots ;) maybe we should amp; instead? Wow. Yeah, I'm really tired this morning. amp; is what I meant, of course... Thanks, Hartmut. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
On Wed, 4 Apr 2001, Alexander Bokovoy wrote: Why do you see it as a problem? They should be doing their own releases after our releases. ie. They should say that this version works with PHP 4.0.5. People should know that when they get the bleeding edge..it might not work at all.. There have been also other changes (e.g. in Zend) which might break those extensions. So I don't really see this renaming as a big problem. I'm not against renaming, I'm warning that CVS and release version will use different macros so extensions will be in trouble till next release based on HEAD branch. And again: The people releasing external extensions should make a releases for certain versions of PHP/Zend as it still is a moving target. IMNSHO. [..] If so, why this change didn't find its way into PHP_4_0_5 branch? It was done a week ago, at the time of ~ RC3 I think. So you think we should break the configure now when the release date is so close? Umm..I really don't understand how THAT would be a good thing to do. I think it's better to give the developers of those extensions enough time to make the necessary changes into their code before a PHP with changed configure is released. Or are you saying that we should break everything in 4.0.5-BOOM ? :) (could we have some nice 'codenames' for the releases? Please.. :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: ; arg seperator
At 00:54 04/04/2001 +0200, Hartmut Holzgraefe wrote: [EMAIL PROTECTED] wrote: Please stop crossposting to the PHP-DEV and the PHP-QA mailing list. Most people interesting in this theme are reading both. And so it is really annoying to get everything twice. a bad idea IMHO as long as the topic is related to both lists as this will break the thread in the archives for one of the lists -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 *** np, --- FOR ARCHIVES : Please follow-up this discussion on [EMAIL PROTECTED] --- No cross-posting please. To subscribe to php-qa mailing-list : PHP Quality Assurance Mailing List http://www.php.net/support.php OR mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
At 06:55 4/4/2001, Alexander Bokovoy wrote: If so, why this change didn't find its way into PHP_4_0_5 branch? It was done a week ago, at the time of ~ RC3 I think. Because changes such as this aren't critical, make break things, and thus do not belong in RCs. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
Quoting Joey Smith [EMAIL PROTECTED]: I've never bought into this argument, because these companies can include a "config.php", or something like that, which uses ini_set() to set up the INI file however they need it... But commercial companies aside, the plethora of configuration options (like magic_quotes_gpc) can and does make life harder for people writing code libraries (like PEAR) that are meant to be dropped in anywhere, or for people trying to write applications that have minimal setup required, or that people can install on hosts where they don't have access to the php.ini parameters. It's certainly something to keep in mind. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Number of U.S. nuclear bombs lost in accidents and never recovered: 11 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
But commercial companies aside, the plethora of configuration options (like magic_quotes_gpc) can and does make life harder for people writing code libraries (like PEAR) that are meant to be dropped in anywhere, or for people trying to write applications that have minimal setup required, or that people can install on hosts where they don't have access to the php.ini parameters. It's certainly something to keep in mind. There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. Is anybody keeping notes ? ;) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote: But commercial companies aside, the plethora of configuration options (like magic_quotes_gpc) can and does make life harder for people writing code libraries (like PEAR) that are meant to be dropped in anywhere, or for people trying to write applications that have minimal setup required, or that people can install on hosts where they don't have access to the php.ini parameters. It's certainly something to keep in mind. There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. Is anybody keeping notes ? ;) I think you just volunteered yourself :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. I'd be completely against removing the concept of magic_quotes altogether. We can discuss changing the default, but for someone writing simple sql pages, it is extremely handy to have PHP deal with escaping stuff for you so you don't have a bunch of addslashes() calls everywhere. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
From: "Rasmus Lerdorf" [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 7:22 PM There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. I'd be completely against removing the concept of magic_quotes altogether. We can discuss changing the default, but for someone writing simple sql pages, it is extremely handy to have PHP deal with escaping stuff for you so you don't have a bunch of addslashes() calls everywhere. Agreed that it's handy and easy, but it's a two-edged sword. If you write scripts that should be distributed on many different servers, it takes a lot of code to account for both settings. I'm one of those control freaks ;) that like to be in total charge about what data goes in and out of my application. magic_quotes most certainly messes with that. There are so many other converting methods in PHP that you need to use, magic_quotes or not, (eg. urlencode/decode), so why must addslashes be a default? - Carsten -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
Agreed that it's handy and easy, but it's a two-edged sword. If you write scripts that should be distributed on many different servers, it takes a lot of code to account for both settings. I'm one of those control freaks ;) that like to be in total charge about what data goes in and out of my application. magic_quotes most certainly messes with that. There are so many other converting methods in PHP that you need to use, magic_quotes or not, (eg. urlencode/decode), so why must addslashes be a default? And that's fine. Control freaks and people writing code for distribution are the same people who can cope with calling get_magic_quotes_gpc() and making their code work. One of the main ideas behind PHP is to make it easy for new users without limiting more experienced users. Occasionally inconveniencing the experienced users is unavoidable in certain cases. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
hi, There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. I'd be completely against removing the concept of magic_quotes altogether. We can discuss changing the default, but for someone writing simple sql pages, it is extremely handy to have PHP deal with escaping stuff for you so you don't have a bunch of addslashes() calls everywhere. perhapse all those topics must be decided on a statistical basis. lets name it: count of boxes broken if arg_separator is ';' count of boxes that dont care about arg_separator default count of boxes that need arg_separator to be ';' count of boxes relying on magic_quotes_gpc count of boxes that dont care about magic_quotes_gpc count of boxes that need magic_quotes_gpc set to off the decision must break least possible count of php setups when they upgrade to the newest version. it would be a disaster for people who have a running server/site and everything or even worse something somewhere goes wrong. not to speak about hosting providers who upgrade farms of servers. their users will have to track problems that occur depending on the input data and mostly in rare cases. i think this will be a negative impact on many sites making people reluctant to upgrade to newer php versions. php4.0.5 is not that better that 4.0.x compared to the difference between 3 and 4 to afford to break existing functionality... b. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
On Thu, 5 Apr 2001, Boian Bonev wrote: count of boxes broken if arg_separator is ';' count of boxes that dont care about arg_separator default count of boxes that need arg_separator to be ';' count of boxes relying on magic_quotes_gpc count of boxes that dont care about magic_quotes_gpc count of boxes that need magic_quotes_gpc set to off And note that in CVS there are now two directives: arg_separator.input arg_separator.output Both default to "" thus were not gonna break anything. I will MFH into 4_0_5 branch tomorrow evening (CET) if nobody objects before that. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: ; arg seperator
Just wanted to toss in my .02 here... Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get "$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented feature. So if it goes away, it goes away. It should never have worked to begin with, IMHO... This doesn't mean it won't bite some people, but that's never been a problem before in cases of undocumented features. On Tue, 3 Apr 2001, Andi Gutmans wrote the following to James Moore, Sascha...: James, You have to be aware that now PHP has such a big user base we need to be very careful in the changes we make especially when we can be pretty certain that it might burn quite a lot of people. We can break compatibility more easily when we have a major release (as from PHP 3 to PHP 4) but these kind of patches need to also be sensitive to the existing users. I personally don't know this issue very well and it is hard for me to guess how many people will be effected. Probably some of you who know this better can get an idea. Also I missed if this is the same directive as in php.ini. Anyway, I'm just saying don't take the user base too lightly because most of them aren't php-dev@ hackers who want the standards but they want their web sites to continue working. Anyway, this doesn't mean I am necessarily against including the patch but we need to make sure we're all OK with it and make a decision not only based on the standard but also on how much damage this might make. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
I disagree, we explicitly document that the arg_separator defaults to and that this is the character that separates url arguments. This follows the original CGI specification. The fact that this is no longer the accepted standard for this doesn't mean we can just up and change it in a minor PHP version. -Rasmus On Tue, 3 Apr 2001, Joey Smith wrote: Just wanted to toss in my .02 here... Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get "$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented feature. So if it goes away, it goes away. It should never have worked to begin with, IMHO... This doesn't mean it won't bite some people, but that's never been a problem before in cases of undocumented features. On Tue, 3 Apr 2001, Andi Gutmans wrote the following to James Moore, Sascha...: James, You have to be aware that now PHP has such a big user base we need to be very careful in the changes we make especially when we can be pretty certain that it might burn quite a lot of people. We can break compatibility more easily when we have a major release (as from PHP 3 to PHP 4) but these kind of patches need to also be sensitive to the existing users. I personally don't know this issue very well and it is hard for me to guess how many people will be effected. Probably some of you who know this better can get an idea. Also I missed if this is the same directive as in php.ini. Anyway, I'm just saying don't take the user base too lightly because most of them aren't php-dev@ hackers who want the standards but they want their web sites to continue working. Anyway, this doesn't mean I am necessarily against including the patch but we need to make sure we're all OK with it and make a decision not only based on the standard but also on how much damage this might make. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: ; arg seperator
On Tue, 3 Apr 2001, James Moore wrote the following: I would question about it being optional in the long term though. If we begin to make everything optional then we get to a point where PHP is so configurable with enabling this bug here or there it becomes impossible to create distribuable scipts that are easy to install and make work (making it difficult for commercial companies to create PHP Scripts to sell which is a bad thing IMHO). I've never bought into this argument, because these companies can include a "config.php", or something like that, which uses ini_set() to set up the INI file however they need it... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
I disagree, we explicitly document that the arg_separator defaults to and that this is the character that separates url arguments. This follows the original CGI specification. The fact that this is no longer the accepted standard for this doesn't mean we can just up and change it in a minor PHP version. Well how about a comprimise then. We keep the broken behavior configurable in the php.ini for now. If needed we default it to off. At 4.1 Which perhaps should not be too far away due to the amount of things like this we default it to on. Then at 4.2 we remove the option? James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Just to reply to myself we are fairly broken here according to rfc 2396 but if you guys think thats acceptable until 4.1 (whenever that might be) then thats fine.. Relavant part of RFC: 2.2. Reserved Characters Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI. reserved= ";" | "/" | "?" | ":" | "@" | "" | "=" | "+" | "$" | "," The "reserved" syntax class above refers to those characters that are allowed within a URI, but which may not be allowed within a particular component of the generic URI syntax; they are used as delimiters of the components described in Section 3. Do we get complaints about + being turned into spaces (I cant find any mention of that in the CGI 1.1 spec)?? No people expect it.. people should expect that all reserved characters are coverted or treated properly (we should make it clear we are rfc 2396 complaint though). Now wether this happens now or at 4.1 is the question.. James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
On Tue, 3 Apr 2001, Rasmus Lerdorf wrote: I disagree, we explicitly document that the arg_separator defaults to and that this is the character that separates url arguments. This follows the original CGI specification. The fact that this is no longer the accepted standard for this doesn't mean we can just up and change it in a minor PHP version. One thing to remember: arg_separator is supposed to be used when PHP _outputs_ urls, like transparent session id's. And not be used when parsing URLs and creating the variables in main/php_variables.c This is said also in php.ini: ; The separator used in PHP generated URLs to separate arguments. ; Default is "". So question is: Should we support ; or in "incoming" urls? Now both work. Which (IMO) is the right way. And if people want to use something like this: foo.php?a=1;2;3, they should url encode the string. Which reminds me: If arg_separator is used like it was before my patch and you set it to e.g. ';' and then have a form which method is GET..well, it won't work. there would be one variable holding all the info. So, another directive into php.ini? (I don't like that idea :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Just thinking out loud here before I go to bed...how about: arg_sep.read = "" | ";" arg_sep.write = ";" Or something like this. It'd be nice to be able to do the |. On Tue, 3 Apr 2001, James Moore wrote the following to Rasmus Lerdorf and...: I disagree, we explicitly document that the arg_separator defaults to and that this is the character that separates url arguments. This follows the original CGI specification. The fact that this is no longer the accepted standard for this doesn't mean we can just up and change it in a minor PHP version. Well how about a comprimise then. We keep the broken behavior configurable in the php.ini for now. If needed we default it to off. At 4.1 Which perhaps should not be too far away due to the amount of things like this we default it to on. Then at 4.2 we remove the option? James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Which reminds me: If arg_separator is used like it was before my patch and you set it to e.g. ';' and then have a form which method is GET..well, it won't work. there would be one variable holding all the info. Urls that are the result of a submitted form are generated by the browser and not php, and I don't know of a browser that will use anything other that '' for that. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
On Tue, 3 Apr 2001, Edin Kadribasic wrote: Which reminds me: If arg_separator is used like it was before my patch and you set it to e.g. ';' and then have a form which method is GET..well, it won't work. there would be one variable holding all the info. Urls that are the result of a submitted form are generated by the browser and not php, and I don't know of a browser that will use anything other that '' for that. Exactly. And that's why if you change the arg_separator to ";" those forms didn't work (before my patch). I actually didn't test it though so I'm not 100% sure. Could someone check it out with 4.0.4pl1? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Which reminds me: If arg_separator is used like it was before my patch and you set it to e.g. ';' and then have a form which method is GET..well, it won't work. there would be one variable holding all the info. Urls that are the result of a submitted form are generated by the browser and not php, and I don't know of a browser that will use anything other that '' for that. Exactly. And that's why if you change the arg_separator to ";" those forms didn't work (before my patch). I actually didn't test it though so I'm not 100% sure. Could someone check it out with 4.0.4pl1? You are right. The following php script: ?php print "a=$abrb=$bbr"; ? form input type="text" name="a" value="1"br input type="text" name="b" value="1"br input type="submit" /form with arg_separator set to ";" in php.ini produces a=1b=2 b= It is clear that documentation in php.ini is wrong, arg_separator is not only used for generation but also for parsing of arguments (4.0.4pl1). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator
Shouldn't the solution be that the parser uses '' *and* arg_separator when arg_separotor is not ''? In that way the default behaviour of php is unchanged. Edin - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: PHP Developer List [EMAIL PROTECTED]; PHP Quality Assurance [EMAIL PROTECTED] Sent: Wednesday, April 04, 2001 12:14 AM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: ; arg seperator Which reminds me: If arg_separator is used like it was before my patch and you set it to e.g. ';' and then have a form which method is GET..well, it won't work. there would be one variable holding all the info. Urls that are the result of a submitted form are generated by the browser and not php, and I don't know of a browser that will use anything other that '' for that. Exactly. And that's why if you change the arg_separator to ";" those forms didn't work (before my patch). I actually didn't test it though so I'm not 100% sure. Could someone check it out with 4.0.4pl1? You are right. The following php script: ?php print "a=$abrb=$bbr"; ? form input type="text" name="a" value="1"br input type="text" name="b" value="1"br input type="submit" /form with arg_separator set to ";" in php.ini produces a=1b=2 b= It is clear that documentation in php.ini is wrong, arg_separator is not only used for generation but also for parsing of arguments (4.0.4pl1). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
On Tue, Apr 03, 2001 at 03:18:00PM -0600, Joey Smith wrote: Speaking of this, I think we need to collect all of these types of issues that are waiting for a "4.1" release somewhere, so we can get a clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If not, I can go search the archives... There is one problem which could come dangerous for extensions in future: change made a week ago in configure macros: AC_ADD_* - PHP_ADD_* This change was made in HEAD branch but PHP_4_0_5 wasn't reflected. It means that external extensions (PHP-GTK, Midgard, APC and others) now in hard situation: they will be broken with CVS snapshots (but will work with 4.0.4pl1, 4.0.5). And then they will eventually work with 4.0.6 but be broken with previous ones. IMO, for external extensions latest version of PHP should not be 'must' requirement, people are conservative usually and would not replace main engine without too much need. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- Sometimes, too long is too long. - Joe Crowe -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
On Wed, 4 Apr 2001, Alexander Bokovoy wrote: There is one problem which could come dangerous for extensions in future: change made a week ago in configure macros: AC_ADD_* - PHP_ADD_* This change was made in HEAD branch but PHP_4_0_5 wasn't reflected. It means that external extensions (PHP-GTK, Midgard, APC and others) now in hard situation: they will be broken with CVS snapshots (but will work with 4.0.4pl1, 4.0.5). And then they will eventually work with 4.0.6 but be broken with previous ones. IMO, for external extensions latest version of PHP should not be 'must' requirement, people are conservative usually and would not replace main engine without too much need. Why do you see it as a problem? They should be doing their own releases after our releases. ie. They should say that this version works with PHP 4.0.5. People should know that when they get the bleeding edge..it might not work at all.. There have been also other changes (e.g. in Zend) which might break those extensions. So I don't really see this renaming as a big problem. This renaming was only done because the configure system is getting pretty big and those macros looked like autoconf one's, a fact that confused me (only me? :) many times. Now if someone would be so kind and documented the usage of those macros a bit better. :-) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: ; arg seperator
On Wed, Apr 04, 2001 at 12:55:52AM +0200, Jani Taskinen wrote: On Wed, 4 Apr 2001, Alexander Bokovoy wrote: There is one problem which could come dangerous for extensions in future: change made a week ago in configure macros: AC_ADD_* - PHP_ADD_* This change was made in HEAD branch but PHP_4_0_5 wasn't reflected. It means that external extensions (PHP-GTK, Midgard, APC and others) now in hard situation: they will be broken with CVS snapshots (but will work with 4.0.4pl1, 4.0.5). And then they will eventually work with 4.0.6 but be broken with previous ones. IMO, for external extensions latest version of PHP should not be 'must' requirement, people are conservative usually and would not replace main engine without too much need. Why do you see it as a problem? They should be doing their own releases after our releases. ie. They should say that this version works with PHP 4.0.5. People should know that when they get the bleeding edge..it might not work at all.. There have been also other changes (e.g. in Zend) which might break those extensions. So I don't really see this renaming as a big problem. I'm not against renaming, I'm warning that CVS and release version will use different macros so extensions will be in trouble till next release based on HEAD branch. This renaming was only done because the configure system is getting pretty big and those macros looked like autoconf one's, a fact that confused me (only me? :) many times. Now if someone would be so kind and documented the usage of those macros a bit better. :-) If so, why this change didn't find its way into PHP_4_0_5 branch? It was done a week ago, at the time of ~ RC3 I think. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- "Here comes Mr. Bill's dog." -- Narrator, Saturday Night Live -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
