Daniel Shahaf wrote on Tue, 05 Sep 2017 14:06 +0000:
> Branko Čibej wrote on Tue, 05 Sep 2017 15:56 +0200:
> > On 05.09.2017 15:45, Daniel Shahaf wrote:
> > > brane_at_apache.org wrote on Tue, 05 Sep 2017 07:45 +0000:
> > >> +svn_client_upgrade2(const char *wcroot_dir,
> > >> + const char* wc_format_version,
> > >> + svn_client_ctx_t *ctx,
> > >> + apr_pool_t *scratch_pool);
> > >> +
> > >> +/**
> > >> + * Like svn_client_upgrade2(), but always upgrades to the newest
> > >> + * supported format.
> > >> + *
> > >> - * @since New in 1.7.
> > >> + * @deprecated Provided for backward compatibility with the 1.7 API.
> > > Why drop @since? We don't usually remove @since tags when deprecating.
> > > (Both here and in svn_wc_upgrade())
> >
> > Yes we do. I looked around and didn't find @since and @deprecated used
> > together.
>
> Counter-examples: svn_cmdline_prompt_baton_t,
> svn_cmdline_create_auth_baton(), svn_txdelta_to_svndiff2().
>
> Functions that have @deprecated but not @since are, the way we've usually
> managed deprecations, supposed to be functions that were present in 1.0.
> (Example: svn_txdelta_to_svndiff())
>
> > The deprecation reason gives the original API version anyway.
> >
>
> This is just a coincidence. We could very well have "@since New in 1.1"
> together with "@deprecated ... for ... the 1.9 API." if we deprecate
> some old function.
This example is for a function that was added in 1.1.0 and first became
deprecated in 1.10.0. Accordingly, the @deprecated annotation on
svn_client_upgrade() should say 1.9, not 1.7.
Cheers,
Daniel
Received on 2017-09-05 16:15:52 CEST