Re: Re: PHP 5.1 (Or How to break tousands of apps out there)
| From: | Sebastian Bergmann | Date: | Sat, 26 Nov 2005 09:10:57 +0000 |
| Subject: | Re: Re: PHP 5.1 (Or How to break tousands of apps out there) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-20508@lists.php.net to get a copy of this message | ||
Rasmus Lerdorf schrieb:
> I know it wasn't an intentional thing, but Derick's view that "Gotcha!
> It's in 5.1.0 now, so you can't change it" doesn't sit well with me
Whether or not Derick did this intentionally and/or for selfish reasons
I cannot say (but I do not think so, since it would be unlike the Derick
I got to know over the years), but even if he did, he cannot be solely
blamed for this as our "process" did not catch it.
I think we should finally stop to commit non-bugfix changes to a release
branch. The release of a first release candidate of a new PHP version
should be a feature-complete state of that new PHP version that only
needs further testing and bug fixing before the final release.
Karl Fogel gives a good overview in [1] on how release testing should
happen:
"The purpose of a candidate is to subject the code to wide testing
before blessing it as an official release. If problems are found, they
are fixed on the release branch and a new candidate release is rolled
out. The cycle continues until no unacceptable bugs are left, at which
point the last candidate release becomes the official release—that is,
the only difference between the last candidate release and the real
release is the removal of the qualifier from the version number."
I think we would win a lot if we would honour the above definition of
release candidates.
--
[1] http://producingoss.com/html-chunk/testing-and-releasing.html
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69