Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85819 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59555 invoked from network); 15 Apr 2015 09:12:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Apr 2015 09:12:07 -0000 Authentication-Results: pb1.pair.com header.from=remi@fedoraproject.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=remi@fedoraproject.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fedoraproject.org from 217.70.183.198 cause and error) X-PHP-List-Original-Sender: remi@fedoraproject.org X-Host-Fingerprint: 217.70.183.198 relay6-d.mail.gandi.net Received: from [217.70.183.198] ([217.70.183.198:36109] helo=relay6-d.mail.gandi.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 23/4F-47925-36B2E255 for ; Wed, 15 Apr 2015 05:12:05 -0400 Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 68324FB923 for ; Wed, 15 Apr 2015 11:12:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id zs+xnjjMuQq4 for ; Wed, 15 Apr 2015 11:11:30 +0200 (CEST) X-Originating-IP: 82.241.130.121 Received: from schrodingerscat.famillecollet.com (pom51-2-82-241-130-121.fbx.proxad.net [82.241.130.121]) (Authenticated sender: contact@ll-experts.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id D3A08FB927 for ; Wed, 15 Apr 2015 11:11:29 +0200 (CEST) Message-ID: <552E2B41.5000306@fedoraproject.org> Date: Wed, 15 Apr 2015 11:11:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Fixing bundled extension version mess From: remi@fedoraproject.org (Remi Collet) Le 15/04/2015 07:08, Xinchen Hui a =C3=A9crit : > Hey=EF=BC=9A >=20 > Sent from my iPhone >=20 >> On Apr 15, 2015, at 10:21 AM, Pierre Joye wrote= : >> >> hi, >> >> We tried that many times but we fail to handle the version of bundled >> extensions. >> >> Along with some installer work and other integration (projects >> dependencies management, composer or other), we need to find a way to >> get rid of this problem. >> >> What do you think to simply use the PHP version number instead of some >> outdated (most of the time) version for all bundled extensions? > in generally, I am +1 on this >=20 > I was also thinking of this yesterday, but the problem with opcache is: >=20 > We already release pecl opcache with version 7.0.X >=20 > If we now use Php version instead, then use may be confused with the ve= rsions? >=20 > Anyway, I still +1 on this >=20 I'm mostly +1 on this proposal. Of course extension (like oci8) should be able to keep its version (when it is correctly managed). Yes opcache have an issue... so we probably have to keep 7.0.x until PHP = 7.1 Most of the others extensions in php-src, version is just a mess. Ex: SPL version 0.2 ? really ? ;) Remi. > Thanks >> For extensions being available both bundled or externally, the >> external versions will provide a sane version number when installed >> (like timezone db or other). >> >> Doing so will make requirements management much easier by adding a >> list of core extensions per PHP version. >> >> Thoughts? >> >> Cheers, >> --=20 >> Pierre >> >> @pierrejoye | http://www.libgd.org >> >> --=20 >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >=20