Re: Versioning (resent due to lack of replies)

Good stuff. Not sure about the extension versioning though, how do you determine from a script which extensions were bundled with PHP and which were not? When we "de-bundle" an extension, should it maintain PHP's versioning to make checks compatible? (Sorry for messing up your nice and clean suggestion :) - Stig [Jani Taskinen <sniper@iki.fi>] > 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 -- Stig Sæther Bakken <ssb@alltheweb.com> Fast Search & Transfer ASA, Trondheim, Norway