commons-dev mailing list archives

https://issues.apache.org/jira/browse/OGNL-232
2013/3/26 Lukasz Lenart <lukaszlenart@apache.org>:
> 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