Re: [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, jimw@apache.org wrote:

Stig Sæther Bakken <ssb@alltheweb.com> 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: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net