On Wed, Mar 6, 2013 at 10:11 AM, sebb <seb...@gmail.com> wrote: > 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.
Guess we need to decide on a few rules here. If they are somehow connected to method naming et al we should look at them more closely > 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 +1 We should look over all of our methods right now and discuss everything which is public. > Speaking of which, there does not seem to be a Clirr report. I have added the clirr report plugin right now. I doesn't report for the first build, as it cannot compare to anything. I am bit confused since there is basically no configuration necessary, just the plugin definition - is it correct? > 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. We have moved OGNL to 4.0 and Apache - should we annotate everything with since 4.0.0 then? Imho it doesn't make much sense to annotate with 3.x, as the package has changed and both releases are not fully interchangeable Cheers > >> [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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
