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:31:15 GMT
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 <lukaszlenart@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 <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