commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <lukaszlen...@apache.org>
Subject Re: [OGNL] A new release
Date Tue, 26 Mar 2013 08:10:45 GMT
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 <grobmeier@gmail.com>:
> On Wed, Mar 6, 2013 at 10:11 AM, sebb <sebbaz@gmail.com> wrote:
>> On 6 March 2013 06:49, Lukasz Lenart <lukaszlenart@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message