2013/3/18 sebb <seb...@gmail.com> > On 18 March 2013 09:17, Jörg Schaible <joerg.schai...@scalaris.com> wrote: > > Simone Tripodi wrote: > > > >> http://people.apache.org/~simonetripodi/ > >> http://simonetripodi.livejournal.com/ > >> http://twitter.com/simonetripodi > >> http://www.99soft.org/ > >> > >> > >> On Mon, Mar 18, 2013 at 9:51 AM, sebb <seb...@gmail.com> wrote: > >>> On 18 March 2013 08:46, Sebb (JIRA) <j...@apache.org> wrote: > >>>> > >>>> [ > > > https://issues.apache.org/jira/browse/DIGESTER-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- > > tabpanel&focusedCommentId=13604945#comment-13604945 > >>>> [ ] > >>>> > >>>> Sebb commented on DIGESTER-171: > >>>> bq. * When adding new classes, it is a good practice adding the @since > >>>> javadoc tag. > >>> > >>> I think it's the job of the Commons developer/release manager to > >>> ensure that the correct @since tags are added. > >>> Seems unfair to ask 3rd parties to work out what the next version > >>> number is - and it may change. > >> > >> The POM always contains the current development version, not a big > >> deal for contributors, especially if they aim to become committers, to > >> get familiar with Commons practices. > > The POM is not always correct; it defaults to the next minor version. > > Sometimes a point release has to be made to fix a regression, and > sometimes a major release bump is warranted. > > So the exact version number is not always known until release preparation. > > In fact this happened recently - the @since version numbers had to be > changed, as the version changed. > > > Actually, for my own projects I always add > > > > @since upcoming > > > > or > > > > @deprecated As of upcoming ... > > > > When I prepare a release I use a the regular expression "s/(since|As of) > > (\s+)upcoming/\1\2VERSION/" to set the proper VERSION. > > Like it, except I tend to use > > @deprecated since 1.2.3 > > I chose TODO because I have that set up to create a task flag in > Eclipse (and it is something to do). > But the exact placeholder is not critical. >
To whatever decision we come here, please let us document it somewhere in the wiki... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
