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
