Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80266 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23392 invoked from network); 8 Jan 2015 09:34:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2015 09:34:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:50470] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/10-21915-E2F4EA45 for ; Thu, 08 Jan 2015 04:34:39 -0500 Received: (qmail 28275 invoked by uid 89); 8 Jan 2015 09:34:36 -0000 Received: by simscan 1.3.1 ppid: 28269, pid: 28272, t: 0.0689s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.169.173.116) by mail4.serversure.net with ESMTPA; 8 Jan 2015 09:34:36 -0000 Message-ID: <54AE4F2C.2040801@lsces.co.uk> Date: Thu, 08 Jan 2015 09:34:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54AAF98B.4020709@gmail.com> <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> <00a201d02ac7$406a4830$c13ed890$@tekwire.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files From: lester@lsces.co.uk (Lester Caine) On 08/01/15 00:50, Pierre Joye wrote: >> What is not clear to me is the question of packaging/versioning/deployment. If you consider the PHP glue code is modified more often than the C code, which will be the most frequent case, how do you version/distribute partial packages ? or do you deliver 2 packages with independent versioning and dependencies together ? In this case, should we define a versioning convention for both packages ? > It is up to the maintainers. I would not do separate releases as it > makes it hard to track or support. Doing more releases even to "only" > fix the PHP glue codes sounds like a good practice anyway. Since the large majority of PHP installs are already handled by third party systems isn't this discussion somewhat academic? I've commented in the past on the discrepancies between different installations, and I still run an 'ini' structure which comes from the SUSE package manager. Separate .ini files for each extension so I can switch extensions on and off simply by the set of files selected. SUSE handled all of the 'install' problems for a particular extension ensuring all the right third part stuff is included and even creating useful PHP additions. The problem nowadays is that each distribution uses it's own set of rules and even the third party windows distributions provide a modular platform with their own way of handling modules, while the main PHP distribution is still handled as a single one off 'core'. I understand the problem that if something gets changed every single extension has to be rebuilt but with all of the tools available today is that really necessary? Can we not come up with a system for PHP7 that allows a security fix to say one of the database packages without needing to recompile the whole installation? Does any current Linux distribution push the whole PHP stack when they include fixes in extensions today? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk