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

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? I mean, obviously this is a development tool so the effects are "maybe" different - e.g. the chances to break production are slim, this would "just" break the development environment. Has this been discussed? 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.] 3) Do you have a pear-category feed so I can add your blog to planet pear, and if not, why not? :D 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 > >