Re: [PEPr] +1 for RFC::Requiring E_STRICT Compatibility for New PEAR Packages

Note: I'm responding to this outside of the formal voting conventions because 1) I should have made this as a comment to the proposal, but just became aware of the proposal this past weekend, and 2) until I actually have a pepr of my own approved, I don't feel like my vote should count. I can't help but think that Lukas has hit on something important with his concerns about the implications of this proposal both for naming and for the inevitable E_STRICT changes introduced in both y and z releases of PHP x.y.z. I think overloading the package name to indicate both API breaks (e.g. MDB vs. MDB2) and supported PHP versions is a mistake. Let's assume, per the example in the RFC, that package Example_Foo is created for PHP 5.1.4 E_STRICT compatibility, with Example_FooPHP4 for PHP 4 usage. When PHP 6 comes out, does Example_Foo get renamed to Example_FooPHP5 and a new package Example_Foo get released for PHP 6 compatibilty? Of course, criticism without at least some alternatives (practical or not) is unfair. So rather than making the package name do everything, would it be possible to make PEAR's package management tools do more to help manage things? The pear command knows which version of PHP is invoking it and could theoretically search for the requested package version that meets its intended needs from an =x.=y.<=z, x.<=y.*, <x.*.* PHP version matching algorithm. (This, by the way, is how my naming counterproposal also gets around the problem with new or changing E_STRICT definitions that may be introduced by the core PHP maintainers in future version bumps). For example: (running with PHP 5.2.0): # pear install MDB2 ... searching for an MDB2 package specifying minimum PHP 5.2.0... ... searching for an MDB2 package specifying minimum PHP 5.*... ... searching for an MDB2 package specifying minimum PHP 4... Found! Installing MDB2... Then, running pear upgrade could also note the currently installed version of PHP and adjust accordingly (so if you were still running on PHP 5.0.3 for some reason and upgraded to 5.2.0, pear could grab updated versions of packages that specified PHP > 5.0.3 and >= 5.2.0). Next question: how are these separate versions of the packages maintained and distributed? Well, we have channels now, and we have branches in CVS. On the surface, at least, it seems like it would be possible to have a pear-5.2 branch that matches a pear-5.2 channel, a pear-5.1 branch that matches a pear-5.1 channel, etc... PEAR also gives us the capability to identify package API version dependencies in the package. It would be nice to be able to use these to avoid having to munge the name (creating, say, MDB3). I don't know, maybe these ideas are too complex to implement and would introduce subtle bugs. But while I'm definitely +1 for requiring new packages to be E_STRICT compatible, I'm -1 for introducing Long_Package_Names_That_Duplicate_The_Purpose_Of_Package_Metadata. Ah, and yet another idea: WIBNI (wouldn't it be nice if) we could make use of our QA architecture to automatically flag packages that are (or are not) E_STRICT compatible for a given PHP version. Standards are good, but tools that help enforce standards (like PHP_CodeSniffer) make it possible to maintain those standards -- or identify problems with the standards. Dan On 5 Sep 2006 20:33:19 -0000, Lukas Smith <smith@pooteeweet.org> wrote:

Lukas Smith (http://pear.php.net/user/lsmith) has voted +1 on the proposal for RFC::Requiring E_STRICT Compatibility for New PEAR Packages. Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=419 Vote information: http://pear.php.net/pepr/pepr-vote-show.php?id=419&handle=lsmith Comment: Example_Foo and Example_FooPhp4 I think the example is not a good idea, as it will introduce yet another naming convention. Since in this example packages will be proposed at the same time it seems more reasonable to make the PHP 4 version the first major version and the PHP 5 version the second following our guidelines. I also want to mention that at this point internals has still not committed to what E_STRICT will really be, how it will progress etc. One possibility is that E_STRICT will get split up in E_STRICT and E_DEPRECATED. In this case this RFC should probably be extended to cover E_DEPRECATED as well. Another "issue" is that there could potentially be new E_STRICT warnings to features not available in previous PHP 5 versions. In that case the policy was always to allow an increasing in the required minor version, but it would probably not be wise to move too quickly to this new minor version. For example PHP 5.3 might introduce an E_STRICT on a feature introduced in PHP 5.3. Fixing the E_STRICT would in effect mean to break compatibility to all previous PHP versions. At any rate, I think its a good idea to pass this RFC now, push internals to further clarify and document E_STRICT and work on solutions to any issues that might arise due to lack of clarification. -- Sent by PEPr, the automatic proposal system at http://pear.php.net -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php