On Mar 29, 2004, at 10:52 PM, kfogel@tigris.org wrote:
> Author: kfogel
> Date: Mon Mar 29 21:51:41 2004
> New Revision: 9229
>
> Modified:
> trunk/HACKING
> Log:
> * HACKING (Release numbering, compatibility, and deprecation):
> Describe the API renaming strategy.
>
>
> Modified: trunk/HACKING
> =======================================================================
> =======
> --- trunk/HACKING (original)
> +++ trunk/HACKING Mon Mar 29 21:51:41 2004
> @@ -1519,6 +1519,23 @@
> svn_cancel_func_t cancel_func,
> void *cancel_baton,
> apr_pool_t *pool);
> +
> +When the major release number changes, the "best" new API in a series
> +generally replaces all the previous ones (assuming it subsumes their
> +functionality), and it will take the name of the original API. Thus,
> +marking 'svn_repos_dump_fs' as deprecated in 1.1.x doesn't mean that
> +2.0.0 doesn't have 'svn_repos_dump_fs', it just means the function's
> +signature will be different: it will have the signature held by
> +svn_repos_dump_fs2 (or svn_repos_dump_fs3, or whatever) in 1.1.x. The
> +numbered-suffix names disappear, and there is a single (shiny, new)
> +svn_repos_dump_fs2 again.
Shouldn't that be "a single (shiny, new) svn_repos_dump_fs again"?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 06:08:48 2004