Re: Re: [ANNOUNCEMENT] PHP_CodeSniffer-1.3.0a1 (alpha) Released.

From: Date: Tue, 31 Aug 2010 06:19:05 +0000
Subject: Re: Re: [ANNOUNCEMENT] PHP_CodeSniffer-1.3.0a1 (alpha) Released.
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-53735@lists.php.net to get a copy of this message
Just a follow-up to this email. I've updated the PHP_CodeSniffer documentation to replace the existing coding standard tutorial with one that uses the ruleset.xml file format and have also added an annotated ruleset.xml file describing all the features and how to use them. This documentation will be available on the PEAR site whenever the docs are regenerated (over the weekend I assume). I've also written a guide to help developers convert their existing custom coding standards over to the new ruleset.xml format. The guide is here: http://www.squizlabs.com/php-codesniffer/upgrading-for-1.3.0 Please feel free to give this information to anyone asking for assistance. Thanks Greg On 13/08/2010, at 9:00 AM, Greg Sherwood wrote: > Hi Mike, > > It's strange you have received comments yourself and yet nobody has contacted me either > directly or via PEAR about backwards compatibility yet. I encourage all developers to get in touch > if they need help converting their standard as I am more than happy to help out while the alpha > process is ongoing. > > 1.3.0 included a big rewrite for a lot of core components and I'm not keen to bloat the > core with a large amount of legacy code. Having said that, I don't intend to leave standard > developers on their own. This is what I've been doing: > > I've gone through and converted all standards that ship with PHP_CodeSniffer to make sure > I have a good grasp of what standard developers will need to do to bring their standards to the new > ruleset.xml format. It's actually pretty easy and I'm writing a doc that will describe how > to get you there. The doc will also cover adding error codes to all error messages to allow other > developers to override the default messages and settings. None of the current sniffs they have > written will break. They just need to remove the single .php file and replace it with a .xml file in > a very similar format. It's a copy/paste job, but one I know (from a lot of experience) that > developers wont do unless they are forced to :) > > I've posted a article, that I link to often, describing the new format and promoting what > it offers. I did this 5 months before the alpha. The alpha really should have come out sooner after > that article, but I had some very distressing issues to deal with in my personal life and had to > take a break from the project, which is why I still link people to that article to try and promote > the new message. > If anyone is interested, the article is here: > http://www.squizlabs.com/php-codesniffer/php_codesniffer-ruleset.xml-support-in-svnóå`¹ Mš > TšC ¤ > > I've done an alpha release and intend to do a fein the w more, and some betas, to ensure > there is plenty of time to convert over standards. The alpha is pretty stable and I do use it in > production to ensure it keeps ticking along, but I'm not about to push a release early (despite > numerous calls for me to do so) because it is a big change and people need to prepare for it. > It's also good to get a bit more testing in there obviously. I think if you look at my pervious > release dates you'll see they I'm not one to just throw new releases out there in a hurry. > > I've also made this a 1.3 release instead of a 1.2.3 to indicate that it is major update > and not a point release with the usual bug fixes and small enhancements. It could almost be a 2.0 > release, but I don't want to go down the road of creating a second package (PHP_CodeSniffer2) > because the message becomes confusing for developers trying to install the package (pear install > php_codesniffer = old unsupported version, for example). > > I hope those points give you, and others, the impression that I'm not rushing this and > have thought about it quite a bit. And hopefully you understand my desire to keep a clean code-base. > Perhaps the fact I maintain this particular package, that resolves mostly around clean code, will > help explain that :) > > Look forward to your comments. > > Thanks > > Greg > > On 13/08/2010, at 5:04 AM, Michael Gauthier wrote: > >> On Thu, 2010-07-15 at 05:04 +0000, PEAR Announce wrote: >>> The new PEAR package PHP_CodeSniffer-1.3.0a1 (alpha) has been released at >>> http://pear.php.net/. >>> >> <snip> >> >> Hi Greg, >> >> This is an impressive milestone for PHP Code Sniffer and certainly >> indicates a bright future for the package. >> >> A number of developers have tried out the alpha and have some concerns >> about backwards compatibility. It seems the change from PHP based rule >> definitions to XML based rules causes problems for people who have >> already developed custom rulesets. >> >> I think an ideal solution would be to provide backwards compatibility >> for the old CodingStandards.php method of writing rulesets and encourage >> developers to update to the newer (and in my opinion better) XML >> rulesets. You could use @deprecated in the API docs to indicate where >> APIs should no longer be used. >> >> While backwards compatibility doesn't have to be addressed for further >> alpha releases, it should be fixed before 1.3.0 goes stable. >> >> Cheers, >> >> >> Mike >> > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > Greg Sherwood Product Development Manager E gsherwood@squiz.com.au Squiz Australia Pty. Ltd. A 92 Jarrett Street, Leichhardt NSW 2040 P +61 2 8507 9900 F +61 2 8507 9988 SUPPORT 13000 SQUIZ W www.squiz.com.au AUSTRALIA UNITED KINGDOM NEW ZEALAND EUROPE UNITED STATES SYDNEY MELBOURNE CANBERRA HOBART BRISBANE SUPPORTED OPEN SOURCE SOLUTIONS

« previous php.pear.dev (#53735) next »