Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
[Andi Gutmans [EMAIL PROTECTED]] At 12:01 PM 9/26/2001 -0400, Joao Prado Maia wrote: On Wed, 26 Sep 2001, Andi Gutmans wrote: I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. That is also true, but we still need a reliable way to check for the version of specific extensions. Having just bumped into an inconsistency between GD 1.6.2 and GD 2.01 output, this would help a lot. However, the problem is already out there and to create code that is truly portable I couldn't rely on even this new (if it ever comes to life) feature. This sort of thing really complicates writing portable code. not just for different platforms but also for different versions of extensions. Just a repository wouldn't help much from the programmer's perspective IMHO, if the current situation continues. I agree completely. We need a way to check what version each extension is. We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7 so that we can get this whole external C extension thing going ASAP? Yes, definitely. But what do you think about the versioning scheme Jani proposed? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
At 12:52 27-09-01, Stig Sæther Bakken wrote: Yes, definitely. But what do you think about the versioning scheme Jani proposed? -1 from me on it the way it is, I don't think that bumping the middle digit for every functionality change is a good idea. Bug-fixes and new functionality is intermixed in our development process. I'd propose copying the Linux/Apache/MySQL approach, where the first digit is bumped in case of a serious infrastructure change/rewrite; The middle digit is bumped for things that strongly affect the way you use PHP (e.g., turning register_globals off by default, or something equally far-reaching); The 3rd digit is bumped for everything else. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote: 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. I disagree. It does seem annoying that when we finally release 4.0.7, 4.0.8 is pretty much ready for its own QA round but I thought about this a lot and I think it's better than the alternatives. It allows us to release a more stable version and it's not such a big deal because 4.0.8 will take a long time to finish QA anyway. Most people I talk to *don't* like having to upgrade every month or two. Even three month releases is relatively tight for them so I think the amount of releases we are doing right now is pretty good. Speaking of 4.0.7, I think it's time for RC3 and then a quick release :) Anyone have anything to commit before that? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
Andi Gutmans wrote: Speaking of 4.0.7, I think it's time for RC3 and then a quick release :) Anyone have anything to commit before that? yes, a bunch of ext/dbplus stuff i won't touch the config.m4 and it does not interfere with other extensions afaik i'm the only one to test it anyway and what is in the RC branch is not really useable yet so things can only improve (there will be an article in the german LinuxEnterprise magazine early in october and i would like to have the extension working at least for it's core functionality as described in the article so that those readers who eventually might want to play with it can use a release and do not have to get a CVS version -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
[Andi Gutmans [EMAIL PROTECTED]] At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote: 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. I disagree. It does seem annoying that when we finally release 4.0.7, 4.0.8 is pretty much ready for its own QA round but I thought about this a lot and I think it's better than the alternatives. It allows us to release a more stable version and it's not such a big deal because 4.0.8 will take a long time to finish QA anyway. Most people I talk to *don't* like having to upgrade every month or two. Even three month releases is relatively tight for them so I think the amount of releases we are doing right now is pretty good. Okay, I can agree that given the current situation, three months is a reasonable release frequency. What I'm after is not really having a new PHP release every two weeks. Often I'm waiting for a new release because of a new/changed/bugfixed extension that comes with it, and in these cases it's frustrating having to wait for three months. The start of this thread was a versioning scheme, and that's still what this is all about, because it's required to solve the problem I'm describing above. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
At 10:48 AM 9/26/2001 +0200, Stig Sæther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote: 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. I disagree. It does seem annoying that when we finally release 4.0.7, 4.0.8 is pretty much ready for its own QA round but I thought about this a lot and I think it's better than the alternatives. It allows us to release a more stable version and it's not such a big deal because 4.0.8 will take a long time to finish QA anyway. Most people I talk to *don't* like having to upgrade every month or two. Even three month releases is relatively tight for them so I think the amount of releases we are doing right now is pretty good. Okay, I can agree that given the current situation, three months is a reasonable release frequency. What I'm after is not really having a new PHP release every two weeks. Often I'm waiting for a new release because of a new/changed/bugfixed extension that comes with it, and in these cases it's frustrating having to wait for three months. The start of this thread was a versioning scheme, and that's still what this is all about, because it's required to solve the problem I'm describing above. I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. Anndi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Wed, 26 Sep 2001, Andi Gutmans wrote: I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. That is also true, but we still need a reliable way to check for the version of specific extensions. Having just bumped into an inconsistency between GD 1.6.2 and GD 2.01 output, this would help a lot. However, the problem is already out there and to create code that is truly portable I couldn't rely on even this new (if it ever comes to life) feature. This sort of thing really complicates writing portable code. not just for different platforms but also for different versions of extensions. Just a repository wouldn't help much from the programmer's perspective IMHO, if the current situation continues. Cheers, Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
At 12:01 PM 9/26/2001 -0400, Joao Prado Maia wrote: On Wed, 26 Sep 2001, Andi Gutmans wrote: I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. That is also true, but we still need a reliable way to check for the version of specific extensions. Having just bumped into an inconsistency between GD 1.6.2 and GD 2.01 output, this would help a lot. However, the problem is already out there and to create code that is truly portable I couldn't rely on even this new (if it ever comes to life) feature. This sort of thing really complicates writing portable code. not just for different platforms but also for different versions of extensions. Just a repository wouldn't help much from the programmer's perspective IMHO, if the current situation continues. I agree completely. We need a way to check what version each extension is. We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7 so that we can get this whole external C extension thing going ASAP? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Wed, 26 Sep 2001, Andi Gutmans wrote: I agree completely. We need a way to check what version each extension is. We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7 so that we can get this whole external C extension thing going ASAP? If I could vote on this I would say yes. A lot of good and reliable code will appear if something like this is implemented. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Wed, 26 Sep 2001, Andi Gutmans wrote: I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. +1 one for this... :-) -\- David Eriksson -/- An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. - Richard B. Johnson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. +1 one for this... :-) Sounds good. I think this would make it easier for the developers of the extensions AND the developers of the 'main' code. The drawback is that it could make it more difficult for someone to determine what he needs to run a certain script. But at the moment, a lot of people compile their own PHP with the extensions they need, so the problem already exists. When using a central repository it should work fine (I think ;) So that's a +1 from me too. Sander. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
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. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Tue, 25 Sep 2001, Stig Sæther Bakken wrote: I think we should be flexible to make this practical, the core of the idea is that you should not get any surprises when upgrading just b, and no API surprises when upgrading m. There's a question about whether the API should be defined as the source API, or also the runtime API, for extensions. I think the API should cover both. But then you will quickly get into double digits for the 'm' version. We already have such versions, they are called strnatcmp() and natsort(). Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-) Well, geez, you had to go and spoil it with one example. :) -Andrei Tomorrow the sun will rise. And who knows what the tide will bring? - Tom Hanks, in Cast Away -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Tue, 25 Sep 2001, Jani Taskinen wrote: Like Zeev said, we release new versions too often anyway. I think we're doing just fine. -Andrei The main reason Santa is so jolly is because he knows where all the bad girls live. -- George Carlin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
At 21:12 25-09-01, Stig Sæther Bakken wrote: [Zeev Suraski [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... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Mon, 24 Sep 2001, Jani Taskinen wrote: 2. General rules for PHP, Zend and PEAR/C-extensions v.m.b (e.g. 4.0.8) v = Functions removed, function behaviour changed, API changes, major parts rewritten. (BC might be broken) m = New functionality added. Only backwards compatible API changes. (100% BC) b = Bug fixes. No new functions added. No API changes. (100% BC) Left out if zero (0). It's going to be pretty tough to not add any functionality while also fixing bugs. Maybe 'b' could be incremented for bug fixes and minor functionality enhancements and 'm' for more extensive new functionality and API changes? 3. Stable/development branches [OPTIONAL] -- Even minor number: stable (x.2.x) branch. Odd minor number : development (x.3.x) branch. (this is not needed for PHP. Our stable branch can be the release branch and the development branch is just the HEAD) Correct. 5. New PHP/Zend API function version_compare() -- proto int version_compare(string version1, string version2 [, string operator]) This function knows this: 4.0.5 4.0.6RC2 4.1.4 4.2-RC1 and returns: -1 version1version2 0 version1 === version2 1 version1version2 We already have such versions, they are called strnatcmp() and natsort(). Extensions can use the same function internally to check the Zend / PHP versions. How do we check PEAR versions, will PEAR class have a standard function that returns version? -Andrei The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. - Ernst Jan Plugge -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
[Andrei Zmievski [EMAIL PROTECTED]] On Mon, 24 Sep 2001, Jani Taskinen wrote: 2. General rules for PHP, Zend and PEAR/C-extensions v.m.b (e.g. 4.0.8) v = Functions removed, function behaviour changed, API changes, major parts rewritten. (BC might be broken) m = New functionality added. Only backwards compatible API changes. (100% BC) b = Bug fixes. No new functions added. No API changes. (100% BC) Left out if zero (0). It's going to be pretty tough to not add any functionality while also fixing bugs. Maybe 'b' could be incremented for bug fixes and minor functionality enhancements and 'm' for more extensive new functionality and API changes? I think we should be flexible to make this practical, the core of the idea is that you should not get any surprises when upgrading just b, and no API surprises when upgrading m. There's a question about whether the API should be defined as the source API, or also the runtime API, for extensions. I think the API should cover both. 3. Stable/development branches [OPTIONAL] -- Even minor number: stable (x.2.x) branch. Odd minor number : development (x.3.x) branch. (this is not needed for PHP. Our stable branch can be the release branch and the development branch is just the HEAD) Correct. 5. New PHP/Zend API function version_compare() -- proto int version_compare(string version1, string version2 [, string operator]) This function knows this: 4.0.5 4.0.6RC2 4.1.4 4.2-RC1 and returns: -1 version1version2 0 version1 === version2 1 version1version2 We already have such versions, they are called strnatcmp() and natsort(). Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-) Extensions can use the same function internally to check the Zend / PHP versions. How do we check PEAR versions, will PEAR class have a standard function that returns version? We'll need to add something like that. Either a function, a standard method or when ZE2 comes a static class variable. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
Stig Sæther Bakken [EMAIL PROTECTED] wrote: Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-) probably not. i've always thought that the change needed to make php's version numbers make more sense is relatively small -- stop ignoring the middle digit, and use it to signify releases. so instead of 4.0.7RC1, you'd get 4.1.0 (on BRANCH_4_1 or whatever). if bugs were found, 4.1.1 would get released. when one of those releases is deemed stable (what would be just 4.0.7 in our current scheme), make it available for download on the download page. (meanwhile, head development is on 4.2.0-dev.) this also avoids the '4.0.6pl1' nonsense we've had to do before, too. just release a new version in that 4.x branch. (and the number of cases where people should need to check version numbers for functionality should be vanishingly small. that's why we have things like function_exists().) i think tying the numbers to some definition of feature additions and bug fixes only provides fodder for rules lawyers. i believe the versioning scheme should be firmly rooted in the development process that actually exists, not some ideal of what it should be. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
There are some customary rules with version numbers. Ignoring them will result in lots of confusion, as most popular opensource projects use them (Linux, Apache, MySQL to name a few). Major version number signifies the 'generation', 2nd digit signifies major changes and/or big new chunks of functionality, and 3rd digit signifies small changes, small feature additions, and bug fixes. Additional qualifiers are added under certain circumstances, if necessary (patch level, beta, etc.). First, you forget that for the vast majority of end users, treating RC's as releases is going to be nightmarish. RC's are a reality check before release, and so far, we haven't had a single RC that was release worthy. Just imagine how much headaches we solved employing this approach. Although pl's are a thing of the past, they weren't nonsensical at all, as you suggest. When there were one liner fixes, which did not affect pretty much anything else (including binary compatibility, functionality and script-level compatibility), releasing a pl made very good sense. That discussion is mostly hypothetical though, as we haven't had any pl's since we started using the RC mechanism, and it's no coincidence. Going with your suggestion essentially recreates the problem (release unchecked code) and solves it, IMHO, in a bad way (release new bug-fix releases often). Zeev At 00:57 25-09-01, [EMAIL PROTECTED] wrote: Stig Sæther Bakken [EMAIL PROTECTED] wrote: Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-) probably not. i've always thought that the change needed to make php's version numbers make more sense is relatively small -- stop ignoring the middle digit, and use it to signify releases. so instead of 4.0.7RC1, you'd get 4.1.0 (on BRANCH_4_1 or whatever). if bugs were found, 4.1.1 would get released. when one of those releases is deemed stable (what would be just 4.0.7 in our current scheme), make it available for download on the download page. (meanwhile, head development is on 4.2.0-dev.) this also avoids the '4.0.6pl1' nonsense we've had to do before, too. just release a new version in that 4.x branch. (and the number of cases where people should need to check version numbers for functionality should be vanishingly small. that's why we have things like function_exists().) i think tying the numbers to some definition of feature additions and bug fixes only provides fodder for rules lawyers. i believe the versioning scheme should be firmly rooted in the development process that actually exists, not some ideal of what it should be. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Tue, Sep 25, 2001 at 03:00:05AM +0200, Zeev Suraski wrote: First, you forget that for the vast majority of end users, treating RC's as releases is going to be nightmarish. RC's are a reality check before release, and so far, we haven't had a single RC that was release worthy. Just imagine how much headaches we solved employing this approach. you are misrepresenting what i said. in what i am saying, something with a number is not automatically release quality, is not automatically listed alongside other releases, and is in absolutely no way different from what we currently tag with a version number that happens to contain the string 'RC' in it. (yes, we haven't had a 'pl' since 4.0.4. of course, that's just because it was decided the memlimit fix for 4.0.6 didn't merit a 'pl' designation. my point was simply that instead of ever making use of that middle digit in our release numbers, we just sometimes tack on a extra digit at the end, and that seems silly to me.) 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. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
