[PHP-DEV] Versioning (resent due to lack of replies) From: Jani Taskinen (sniper <email protected>)
Date: 09/14/01

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 <email protected>>]
>> [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 <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>