Re: Versioning, again (was: RE: [Zend Engine 2] Re: PHP is not case sensitive?)

I was thinking of PEAR too, don't worry. :) But the versioning scheme/rules for PHP must be strict. Consider following: We have a numeric version constant: PHP_VERSION_NUM the value for this is calculated with this simple formula: v.m.b = v * 10000 + m * 100 + b v = Changes only when there are big BC breaking changes or when there are big portions of code rewritten, deprecated functions removed, functions behaviour changed..etc. m = Changes only when new functionality is added. b = Bug fixes ONLY. No new functions added. No API changes. examples: 4.0.7 = 40000 + 0 + 7 = 40007 4.1.1 = 40000 + 100 + 1 = 40101 Having PHP_VERSION_NUM would allow PEAR modules (or any other PHP script) to check the version. For example: Module A depends on functions added in version 4.3.2. They could use something like this: if(PHP_VERSION_NUM < 40302 || PHP_VERSION_NUM > 50000) { die("Incorrect PHP version."); } Now if we would follow the rules for versioning set above, they could also trust that this check would work always too. As there could not be any BC breaking changes between major numbers. And also the extensions must follow the same rules as the core PHP. ie. every extension defines it's own version number, calculated with same formula: GD_EXT_VERSION = 30201 Now someone can step forward and tell me that this is already possible. If not, then I would like to know if all of the developers agree on this. And if not, WHY. :) --Jani On 11 Sep 2001, Stig Sæther Bakken wrote: >[Jani Taskinen <sniper@iki.fi>] >> [this is more php-dev stuff, thus moved there] >> >> Warning: >> >> This is yet another beaten up issue but as it still hasn't >> been fixed, we need to find a solution to fix it. >> >> >> Problems: >> >> Viability, BBC, WTFF, old extensions used with new PHP version. >> >> >> Proposals: >> >> My proposal is that first we come up with a versioning scheme >> with which everybody can agree on. Then we can release this >> scheme to 'public' and hopefully not have to discuss/fight >> about this again. >> >> >> Examples: >> >> >> http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html >> >> http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html >> http://www.zenspider.com/ZSS/Definitions/Versions.html >> >> (the last one is something that I'd like to see for PHP) >> >> >> Also, to make NEWS file more useful than it is now I (again) >> propose that it is reorganized like this: >> >> Categories: >> >> ! Important note >> * Changed >> + Added >> - Removed >> >> >> Reasoning: >> >> There has to be clear document that describes when and why a version >> number changes. If someone doesn't understand WHY this document is >> needed they should read the rest of this email. :) >> >> >> --Jani >> >> p.s. Rest can be safely ignored. It is just there to show what happens >> everytime this issue raises it's ugly head and shouts: "BOO!".. > >Take a look at http://cvs.php.net/co.php/pearweb/sql/design.txt. >There's a versioning section at the end there, intended for PEAR. >Anything we can use? > > - Stig > >