Versioning (resent AGAIN due to lack of replies)

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 always work. As there could not be any BC breaking changes between major numbers. (e.g. 4.0.0 < x < 5.0.0) 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 > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net