Re: mbstring and 4.3.0

At 10:53 13-11-2002, Wez Furlong wrote:

On 11/13/02, "Derick Rethans" <derick@php.net> wrote: On Wed, 13 Nov 2002, Marcus Börger wrote:

At 04:11 13.11.2002, Jani Taskinen wrote:

    Since when have we started to use users as guinea-pigs
    for testing EXPERIMENTAL extensions without them even
    really knowing about it?!!

mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works .

uhm, I don't think it works stable enough. Which part of "have used it in production for 2 years with 0 problems" means that it's not stable? :) The parts that myself (and Marcus) want to push *are* very stable. Let's just disable the non-stable, lazy programmer hacky parts by default and everyone will be happy.

FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. * Getting real bug reports is a good thing(tm). Breaking compilation because of sloppy symbol protections sucks(r). The number of bugs should not be a factor in this scenario, because once it becomes core, you're gonna have to deal with them anyway. * Enabling by default for 4.3.0 is actually the best point in time, unless there's going to be a 4.4.0. You don't want this to be done in 5.0.0, because the new OO layer, other new features and especially BC-breaking issues will have to be focused on. (I'm not saying PHP 5 is intending to break BC - just that there is a high probability issues arrise, which we're not foreseeable). A x.x.0 release is the best release to do it in, because people who demand a high level of stability already will skip it and still it will have a large enough audience to flush out the bugs nobody thought of. All in all - I think we should enable the parts mentioned by Wez, in RC1. The default behavior should be "it's compiled in, but doesn't impact any functions". If there is a large number of distinct bug reports, then it's obvious the extension is not mature enough for it and because of the schedule (not the number) it should be disabled in the final release. This is of course based on the assumption, that there are no unresolved bugs with the 'stable parts' at present. With kind regards, Melvyn Sopacua <?php include("not_reflecting_employers_views.txt"); ?>