On 6 March 2013 06:49, Lukasz Lenart <lukaszlen...@apache.org> wrote: > Hi, > > I was checking out what should be solved before releasing a new > version and in my opinion most of PMD [1] errors can be omitted, maybe > "These nested if statements could be combined" should be resolved, but > the rest I don't see a point instead of just satisfying PMD itself. > > Some of the Findbugs [2] errors are related to generated classes, > should I exclude them? > > Another thing is Checkstyle [3], especially "Missing a Javadoc > comment." - I don't know what to put as it without analysing source > code deeply. > > My question is what really should be solved to be ready to release a > new version?
I don't personally worry too much about PMD or Checkstyle; they depend so much on the rules chosen. Findbugs is more useful, but it looks like most of the errors are for generated code. Bugs can be fixed by a new release, but future binary compatibility can easily be compromised. Once a bad or broken API is released, it's very difficult to fix it. So I would say the most important aspect to get right is to fix anything that makes it more difficult to maintain binary compatibility in future. For example, if one of the new methods has a name that is non-standard, it is easy to change it now. Likewise, if there is a new public method which should be private or package protected, do it now. Or new non-private mutable variables - they make thread-safety - and testing - much more difficult Speaking of which, there does not seem to be a Clirr report. That's very important. Apart from checking for unintended compatibility issues, it is useful in ensuring that new classes and methods etc. are annotated with @since markers. > [1] http://commons.apache.org/proper/commons-ognl/pmd.html > [2] http://commons.apache.org/proper/commons-ognl/findbugs.html > [3] http://commons.apache.org/proper/commons-ognl/checkstyle.html > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
