[[EMAIL PROTECTED]]
> 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().)
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 <[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]
