Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions From: Stig Sæther Bakken (ssb <email protected>)
Date: 09/26/01

[Zeev Suraski <zeev <email protected>>]
> At 21:12 25-09-01, Stig Sæther Bakken wrote:
> >[Zeev Suraski <zeev <email protected>>]
> > > 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 <email protected>>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>