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 Javadoc. > 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
