Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33085
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.168 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:sender;
        b=Y6eICK7wed8G8KZkrGFXQMG6llVqvPz0AYoK287KmAVQb7oXvHWox37RGJvlhGpQ6vrZ1cHrSpbQQKRP91jSg/q88F4n2VYlAvrWO6+HE8AXlicqQ3kyzYKkQdb3hke09XRYIUP5OpsXTqJI6Hwqtjw7P4nz13Ctep1cwWenRj4=
Message-ID: <4736156F.1040202@ez.no>
Date: Sat, 10 Nov 2007 21:32:47 +0100
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: internals@lists.php.net
CC: Antony Dovgal <tony@daylessday.org>
References: <47360449.3020007@ez.no> <47360BE3.7010207@daylessday.org>
In-Reply-To: <47360BE3.7010207@daylessday.org>
Content-Type: multipart/alternative;
 boundary="------------040801050907080100060507"
Sender: Gaetano Giunta <giunta.gaetano@gmail.com>
Subject: Re: [PHP-DEV] Re: PHP 5.2.5 Released - update on extensions versioning
 information
From: gg@ez.no (Gaetano Giunta)

--------------040801050907080100060507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

...
>> - oci extension ONLY updated version info (1.2.3 to 1.2.4) but NOT the code!
>>     
>
> OCI8 is (still) a PECL extension, so it's release cycle is not synced with PHP.
>   
Yes I know. We have been testing recent versions a quite bit lately 
because of a strange problem with cursors remaining open (happens when 
the oracle server is windows and oci client is > 1.2.2).

But if the oci8 code that was released as part of php 5.2.4 is exactly 
the same as what is found in pecl version 1.2.4, leaving it tagged 
"1.2.3" is a bit misleading.
Checking dates, pecl 1.2.4 was released the day after php 5.2.4. I do 
not need to scan this list's archives to be sure that everybody involved 
in the oci code knew quite well about the pending release of php, and 
changing that single line of oci code where the version is stored would 
not have been a huge deal. If there really was no certainty that the php 
code would end up being the same as pecl 1.2.4, it could have been 
tagged 1.2.4-dev or something like that...

Please note that I did not intend to single out oci coders as the bad 
guys: I am actually quite happy that at least the oci extension gets 
some version info at all!
> Actually, other PECL extensions should be released through PECL either, but for some 
> reason most of the authors do not do it after the extensions have got into the core.
>
> Speaking of the versions, I believe core extensions should update their versions 
> only after some major changes/additions, which rarely happen in a bugfix branch (if at all)
There are 2 problems with this, imho:
1 - sometimes extensions get moved out of core into pecl (such as... oci? ;)
2 - it is possible on unix to either upgrade or downgrade at will a 
single extension buy just recompiling it. I am not suggesting that it 
always makes sense or that lots of people do it, but it is possible, and 
makes any check-for-presence-of-a-given-bug that depends only on the php 
version much less reliable. People on windows can also do it without 
even recompiling, by just swapping the dlls, provided they can find the 
version they want on pecl4win or from other places.

plus a 3 numbered version is very easy to assign to a lib (you know, 
like a new param for a function bumps up the middle number, a fix - any 
fix - bumps up the rightmost one etc... ) , and every single coder on 
earth is bound to understand it at first look...

But maybe I misunderstood the meaning of "core" above for "bundled"...

Bye
Gaetano

PS: I forgot in my previous mail: CONGRATS FOR THE NEW RELEASE!!!

--------------040801050907080100060507--