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]
