RE: [PECL-DEV] Prefixing names of new filter functions with filter_

Ilia, As I said, I completely understand that you are frustrated. I did not review the ext/filter APIs and I guess many others didn't either, so I like others take blame for waking up too late. I guess that's the nature of open-source projects, where people wake up a bit too late because they are busy or consumed at the time when things happen. Definitely sucks but as I said, we've woken up in time so let's make the best of it. I'm fine with either unsymlinking for 5.2.0 or doing another RC after fixing up the APIs. If we go down the former route, I'd recommend to work towars a 5.2.1 pretty soon because ext/filter is a very important extension and makes a statement that we care about security. Thanks! Andi > -----Original Message----- > From: Ilia Alshanetsky [mailto:iliaal@gmail.com] On Behalf Of > Ilia Alshanetsky > Sent: Friday, September 15, 2006 8:40 AM > To: Andi Gutmans > Cc: 'Derick Rethans'; 'Dan Scott'; 'PECL' > Subject: Re: [PECL-DEV] Prefixing names of new filter > functions with filter_ > > Andi, > > I'm just frustrated by the fact that yet again we have "trivial" > things like naming issues pop-up before the final release, > while being silent through out the earlier release process. > Well, I most certainly don't suggest we ship one set of > functions in 5.2.0 and rename them in 5.2.1, this why I > suggested function aliases. Tthe feedback that I am hearing > from Derick and Pierre, who are the leads on the extensions, > I think we should just take it and wait until it is ready > before including in the future. So, let's remove the symlink > and revisit the issue once the developers can get their heads > around naming a couple of functions. > > On 15-Sep-06, at 11:18 AM, Andi Gutmans wrote: > > > Ilia, > > > > We haven't been "shipping" this extension. RC's are not > considered to > > be shipping, they never have and never should be. > > How can you think of shipping something when you know > you'll need to > > clutter the symbol table with non-coding standard names > which you plan > > to alias in the next release? I think as release manager if > you know > > you're going to ship something which you need to BC-fix in the next > > mini release then it shouldn't ship. > > In that case, if you don't want to ship without ext/filter > I suggest > > one more RC. Frustrating, sure? But you shouldn't let > frustrating get > > to your release quality judgment. > > > > Andi > > > >> -----Original Message----- > >> From: Ilia Alshanetsky [mailto:iliaal@gmail.com] On Behalf Of Ilia > >> Alshanetsky > >> Sent: Friday, September 15, 2006 8:10 AM > >> To: Andi Gutmans > >> Cc: 'Derick Rethans'; 'Dan Scott'; 'PECL' > >> Subject: Re: [PECL-DEV] Prefixing names of new filter > functions with > >> filter_ > >> > >> > >> On 14-Sep-06, at 5:44 PM, Andi Gutmans wrote: > >>> As we have yet to bundle ext/filter I suggest to not bundle it in > >>> 5.2.0, take a week or two to finalize the extension, and > ship it in > >>> 5.2.1. > >>> If there > >>> are any binary compatibility patches in the core, we could > >> keep those > >>> in and just not use them until 5.2.1 is shipped. > >> > >> I think it would be a big loss for us to shop 5.2.0 without the > >> filter extension, which IMHO is a major security > enhancement for PHP > >> and one the "big" things why would someone upgrade to 5.2 would go > >> away if we don't include filter. Also, as Pierre had correctly > >> mention, we've already been shipping PHP with this extension for 3 > >> RCs. Since we've all made the decision to include filter (right or > >> wrong) we need to retain this functionality. > >> > >> Ilia Alshanetsky > >> > >> > >> > >> > > > > -- > > PECL development discussion Mailing List (http://pecl.php.net/) To > > unsubscribe, visit: http://www.php.net/unsub.php > > > > > > Ilia Alshanetsky > >