On Nov 14, 2010, at 20:23, "sebb" <[email protected]> wrote:
> On 15 November 2010 04:16, Gary Gregory <[email protected]> wrote: >> On Nov 14, 2010, at 20:04, "sebb" <[email protected]> wrote: >> >>> On 15 November 2010 03:59, Gary Gregory <[email protected]> >>> wrote: >>>> On Nov 14, 2010, at 19:56, "sebb" <[email protected]> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
