At 10:53 13-11-2002, Wez Furlong wrote:
FWIW:On 11/13/02, "Derick Rethans" <[EMAIL PROTECTED]> 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.
* 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"); ?>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
