Let's do this: try to fix it in the next version. If someone
discovers that we broke their code we will revert it. How does it
sound?
Gee... not on a technical, but more on a philosophical side: is this
a wise thing to do? It means that you have to be damm sure that someone
(a) can find out in time that the code is broken and (b) immediately (or
at least rather soonish) knows that it is broken by this intervention.
Gee, since when philosophy started to block the progress?
Live services aren't supposed to upgrade to a new version of any software before it has been tested on their staging machines. If someone does and something goes wrong, too bad for them.
If someone does the testing on their staging/dev machine and learns that we broke their code, we go and fix it, releasing a new version. I see no problem with that approach. It's not like mod_perl gets its releases once a year, as it used to be. On the opposite, with the stable mod_perl 1.0 we saw many more recent releases.
Don't forget that we have a non-deprecated feature that someone relies on and it's buggy, we have a solution, which we think is good (at least I think so). Why should that user suffer?
If you don't pass a scalar reference to print() this change doesn't affect you. So it certaintly won't affect most of the people, doing plain print.
Now, unless someone wants to contribute a technical reasoning for not committing Rafael's patch, let's move on and not get into a long philosophy thread. We have a way too many bugs and missing features that require our attention, and too few hands willing to do real work.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
