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

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