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

On 31/08/2010, at 5:40 PM, till wrote: > Nice tutorial, Greg. > > Three things: > > 1) Do previous coding standards still work, like is there a > transitional period? I might be late to the party, but I didn't think > BC breaks are allowed in 1.x, I thought you had to do phpcs2 then? The transition period has been (kind of) ongoing since about Feb, when I first posted information about the change. But I'm aware that this is a big change for custom standards so the next release is only in alpha and will not be released as stable for a few more months at least. Plus I've only just found the time this year to get this guide out now, so I'm not racing for a stable release. Not a big fan of the whole Package2 thing after the confusion that was caused by PHPUnit, hence the BC break for custom standards in here. Plus it's a command line tool rather than a lib, so probably a bit different again. > > 2) Could you add something like "phpcs --create-skeleton MyStandard" > so people can get something to start out with? [I can open a feature > request too.] I certainly could. Please do open a feature request so I don't forget :) > > 3) Do you have a pear-category feed so I can add your blog to planet > pear, and if not, why not? :D I only have one package, so all PHP_CodeSniffer news goes through this feed: http://www.squizlabs.com/feeds/phpcs.xml Thanks Greg > > Till > On Tue, Aug 31, 2010 at 8:19 AM, Greg Sherwood <gsherwood@squiz.com.au> wrote: >> 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 >>> >>> 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 >> >> >> >> -- >> 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