Re: [RFC] Versioning rules for PHP/Zend/PEAR/Extensions

From: Date: Wed, 26 Sep 2001 08:58:21 +0000
Subject: Re: [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
References: 1 2 3 4 5 6 7 8 9  Groups: php.dev 
Request: Send a blank email to php-dev+get-66745@lists.php.net to get a copy of this message
[Zeev Suraski <zeev@zend.com>] > At 21:12 25-09-01, Stig Sæther Bakken wrote: > >[Zeev Suraski <zeev@zend.com>] > > > At 03:12 25-09-01, Jim Winstead wrote: > > > >and i do question, a little bit, how successful our new release > > > >strategy is when we only seem to be able to muster a new release every > > > >three months. but maybe that's a pace we're happy with. and of course, > > > >that has way more to do with a great many more issues than how we > > > >number the releases. :) > > > > > > As a matter of fact, one of the most serious complaints I've been > > > hearing from people is that we release way too often. Among others, > > > that makes ISPs mad at us, since it's a logistical nightmare to keep > > > current. > > > >And guess why? Because a new PHP release also carries with it a whole > >Tampa-load of new or changed extensions. Some of these extensions > >have non-BC changes (as with the recent domxml bruhaha), others have > >bugs fixed while some just rot. That's your logistical nightmare > >right there. :-) > > Very true, but that's just a partial part of the problem. It implies > that if it wasn't for those BC breaking changes, it would have been > easy, but that's true only if you have one or two servers. With lots > of servers, it's a big headache even if backwards compatibility is, > God forbid, kept. :) > > >One of the reasons Jani went ahead and proposed the versioning > >standard is to prepare ourselves for "operation extension detach". > >How do you version extensions that we bundle today? The only way > >right now is to use the PHP version. So we should start versioning > >each extension preparing for independent existence. Then we need a > >ruleset like Jani proposes. > > I think that regardless of anything, adding a standard version > information to the extension structure is a good idea. It's a pity we > haven't done that in 4.0.7, as this is a version where we put in > *lots* compatibility breaking changes in the module API. > > >But just to get back to release frequency, I do think we release too > >seldom. There's a lot of process in place now, with a QA branch and > >all. I think this process is good, but it's congesting. At this > >point we're almost ready to start the 4.0.8 release before 4.0.7 is > >through the needle's eye. There's simply too much weight. For every > >extension we shake off, it the release process gets lighter, and some > >ISP sysadmins may even get their hair back. > > My bottom line is that I don't think we release too seldom - a release > every 3 months is a fairly good pace in my opinion. I do think that > the RC cycle may be taking too long, and in this particular case, I > think I bare most of the fault. I lost most of my focus ever since > the WTC went up in flames. However, note that a huge bug was found > only after RC2, weeks into the RC process - completely broken thread > safety mode, thanks to yours truly... I certainly won't blame you (or anyone else) for being preoccupied or having focus problems after what just happened. The release frequency is a sidetrack as far as this thread is concerned, it's not where the problem focus should be. The important issues as I see them are: 1) agreeing on a versioning scheme 2) adding C/PHP functions that implement the logic of this scheme 3) adding enough versioning information to extension libraries - Stig -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway

« previous php.dev (#66745) next »