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

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 >