On Nov 14, 2010, at 20:23, "sebb" <seb...@gmail.com> wrote:
> On 15 November 2010 04:16, Gary Gregory <ggreg...@seagullsoftware.com> wrote: >> On Nov 14, 2010, at 20:04, "sebb" <seb...@gmail.com> wrote: >> >>> On 15 November 2010 03:59, Gary Gregory <ggreg...@seagullsoftware.com> >>> wrote: >>>> On Nov 14, 2010, at 19:56, "sebb" <seb...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
