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 version1 < version2
> 0 version1 === version2
> 1 version1 > version2
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]
