Re: [PHP-DEV] Versioning (resent due to lack of replies) From: Stig Sæther Bakken (ssb <email protected>)
Date: 09/14/01

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 <email protected>>]
> 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> 

-- 
  Stig Sæther Bakken <ssb <email protected>>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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>