Ok, done. Should I just commit the changes? Or do I have to register an issue first in JIRA? Maybe it will be better...
Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/3/26 Lukasz Lenart <lukaszlen...@apache.org>: > I'm not sure what API should be removed/renamed/etc as almost > everything is public static ;-) > > Anyway, I'm trying to remove two deprecated classes right now. > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > 2013/3/8 Christian Grobmeier <grobme...@gmail.com>: >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
