what about a Linux-Kernel like numbering scheme?
- declare 4.0 as stable, only bug and security fixing allowed
- start 4.1 as developement, this is where experiments take place and
new extensions are added
- 'grown up' extensions may be copied to the stable 4.0 version as
soon as they have become stable themselves
- new core features _may_ be ported back if and only if they can be
integrated into the stable version without module api changes
- every once in a while we take what has piled up in the developement
branch and decide what is going into a new stable version and what
is not yet ready for prime time but has to stay in a new developement
- whenever a new stable branch is going to come there will be a feature
and a code freeze phase for the developement branch until it is ready
for
release and a short phase after release before the new developement
branch is opened to get developers concentrated on stability instead
of new features ...
we're not living in an optimal world, I guess this would fail - how do
developers reveal bugs?
a) they're using their extension for some dedicated purpose and all bugs
will be revealed using it in a very special case and thus fixed to
enable using it further, personally
b) bugs will be revealed by users who're *using* these extensions on
completely different environments and in a different manner, as far as a
feature is present (if buggy or not) people try to use it
how do you decide that a feature has "grown up"? Offer downloading 2
verions, one marked "stable" the other marked "development"? how do you
ensure that people are trying their apps with "development" versions and
not switching from "stable" to "stable" and problems show up then?
sure, I'd consider "asymmetric encryption" and "compressed output" not
being stable, but when is the date I do?
just to name such an issue regarding the CORE language: I thought
returing variables by references originating from methods is supported
and ought to work, because it worked for me all the time and nothing
negative is said in the documentation (you could argue that it isn't
documented at all, what would criticize the documentation ([1] either it
should tell us not to do this or [2] it should tell us that it's
possible in unawareness of possible failures)
now zeev told me that it never should have worked properly at all, thus
PHP has been UNSTABLE for many months
Most people spending their free time on extensions don't have the
ressources to do some scientific regression testing, thus regarding
*functions* you cannot decide whether a version is stable or not (except
common ones, eg. mysql)
regarding functions it should be possible writing a regression test
suite covering all basic functions and core language constructs in most
widespread usage (regtests have been resurrected but I don't know if
such tests are included)
I personlly dislike the linux kernel numbering, preferring mysql
versioning (version numbers for features, gamma,beta,alpha sufix for
stability) - in addition you can download the last 6 (maybe 7) versions
if a specific version does not work for you
It would be nice if everyone takes part in this discussion to force
things like experimental branches, PEAR improvement to cover C and
PHP-class extensions, bug-QA (means forcing devs to close specific
serious bugs) or to reject these as methods that do not belong to the
PHP spirit (development)
regarding QAT (building+testing+bugs) I think there's some progress recognizable and that it'll end up positively
sporadically there are some nice discussions but I yet have to see the
effects, perhaps someone with widespread php activities and
knowledge should take care of these things as a "designated coordinator" with responsibility or whatever to ensure that "commercial frustration" (citing Thomas) and user frustration are foreign words in PHP
2c