commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject Re: [VFS] @since markers missing - ctd
Date Mon, 15 Nov 2010 04:43:47 GMT
On Nov 14, 2010, at 20:23, "sebb" <sebbaz@gmail.com> wrote:

> On 15 November 2010 04:16, Gary Gregory <GGregory@seagullsoftware.com> wrote:
>> On Nov 14, 2010, at 20:04, "sebb" <sebbaz@gmail.com> wrote:
>> 
>>> On 15 November 2010 03:59, Gary Gregory <GGregory@seagullsoftware.com>
wrote:
>>>> On Nov 14, 2010, at 19:56, "sebb" <sebbaz@gmail.com> wrote:
>>>> 
>>>>> Starting a new thread because the original one drifted into @author tags.
>>>>> 
>>>>> I've been using clirr to report which classes and methods are new.
>>>>> 
>>>>> This works fine for classes, however Clirr does not seem to notice
>>>>> when a private method becomes public - it just says the method has
>>>>> been added, [even if one tells clirr to process all access modifiers.]
>>>>> 
>>>>> In a sense, this is a method addition - should the @since tag be added?
>>>> 
>>>> +1
>>>> 
>>>>> If so, should we say that the access has changed?
>>>>> For example: @since 2.0 (was private)
>>>> 
>>>> -1
>>> 
>>> What about changes from protected to public?
>>> 
>>> How should these be documented?
>> 
>> Great question. Should it be @since 1.0 or 2.0?  The API will look new to com.foo
client code, so that argues for a plain since 2.0. If I was already a call site of the API,
seeing since 2.0 might look strange but since the scope changed it is understandable. So I
would just argue for since 2.0.
> 
> The reason I suggested adding a comment about the previous
> accessibility was to avoid the possible confusion.
> 
> The Clirr report should show such changes; if not they probably ought
> to go into the release notes.
> 
> However, it might still be useful to mention the change in the 

Sure. Some historical note in the javadoc sounds good. 

GG 
> 
>> GG
>> 
>>> 
>>>> GG
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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