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

[jimw@apache.org] > 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().) Oh, but there are differences a lot more subtle than whether a function exists. That's the whole point of having a version numbering scheme that represents an API. > 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. I think it has to be something in between. For example, the major number should be rooted in the architecture, technical design and development process. But as a user of some piece of software I want version numbers to be more meaningful than Microsoft's. - Stig -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway