JC>> > that apache 2 / PHP 4.2.0 is stable enough for production yet, and
JC>> > therefore recommend to drop the apache2filter from the release branch. "If
JC>>
JC>> I definitely agree that we need to make sure that we do not release a
JC>> version we consider stable and have it crashing due to the apache 2 stuff.
Actually I personnaly don't think 'we cannot declare it stable' leads to
'we cannot release it'. Why just not say 'Apache 2 support is unstable,
use it on your own risk and only if you know what you are doing'?
If it was something that could be in ~/dev or ~/extras directory or whatever, that would make more sense...
If MySQL segfaults, I mean, really, you're looking at a pre-alpha as far as PHP is concerned...
At any rate, we're not like ripping out something from what's been QA-ed, nor adding something in to rush to match Apache 2, I would hope.
If somebody wants to document it somewhere as something to be tried by the foolhardy ^H^H^H^H^H^H^H^H^H brave, and that's what is in the QA-ed software now, that would be perfect.
I don't think anybody is saying hold off on "releasing" it so much as not documenting it as a "released feature"
Jani Taskinen writes:
I'd rather have 4.2.0 released without the apache2 support
and work on the code to get it work for real and release
4.2.1 with the fixed support.
IMHO, removing Apache2 support will not affect the number of
Apache2-related bugs reported. If anything, removing it will
cause more.
Why not leave it in there, mark it as beta/unstable and be
vocal about that in the release announcement.
Agreed -- Don't rip something *OUT* during the middle of RC, no matter how sure you are that "it won't affect anything".
Document the hell out of it as "DEVELOPMENTAL EXPERIMENTAL" and move forward.
--
Got Music? http://l-i-e.com/artists.htm