You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/09/08 14:42:10 UTC
Re: svn commit: r10835 - trunk/subversion/include
maxb@tigris.org writes:
> --- trunk/subversion/include/svn_io.h (original)
> +++ trunk/subversion/include/svn_io.h Mon Sep 6 01:05:04 2004
> @@ -362,7 +362,7 @@
> apr_pool_t *pool);
>
> /**
> - * @deprecated Provided for backward compatibility with the 1.1.0 API.
> + * @deprecated Provided for backward compatibility with the 1.0.0 API.
> *
> * Lock file at @a lock_file. If @exclusive is TRUE,
> * obtain exclusive lock, otherwise obtain shared lock.
> @@ -374,7 +374,7 @@
Is this the right change? When deprecating something, we should say
it's "provided for backward compatibility with" the earliest
Subversion possible, since that implies all later ones anyway.
Saying 1.0.0 API here would imply the 1.1.0 API too, but saying 1.1.0
doesn't include 1.0.0. Don't we want to include both?
This only applies to the "@deprecated" portions of this commit, not
the "@since" changes, of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10835 - trunk/subversion/include
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> No, r10835 was made in response to the nomination and approval of r10467
> and friends into 1.1. Quoting from the erstwhile STATUS entry:
I don't know how I'm missing such obvious things, Greg, sorry.
I think I need to step away from the computer for a while :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10835 - trunk/subversion/include
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-09-08 at 13:18, kfogel@collab.net wrote:
> This change was on trunk, so aren't we deprecating in 1.2?
No, r10835 was made in response to the nomination and approval of r10467
and friends into 1.1. Quoting from the erstwhile STATUS entry:
Note:
HEAD as of r10734 shows the new functions as "since 1.2.0" and the
deprecated functions as "preserving the 1.1.0" API. If these candidates
are approved, then a new trunk revision, marked rXXXXX above, should
also be applied to reflect that the changes were actually included
in 1.1.0.
UPDATE: r10835 is that trunk revision. Since the notional rXXXXX has been
here throughout the voting process, adding in the real revision does not
invalidate the votes.
> I don't understand this.
mbk committed r10467. He didn't expect his change to make it into 1.1,
so he said his new functions were new in 1.2 and (in r10734) deprecated
the old ones as preserving the 1.1 API. (You would argue that he should
have deprecated the old ones as preserving the 1.0 API, but I disagree,
as I argued in my previous message in this thread.)
After the esr thread, mbk nominated r10467, making a note that if it was
approved, the comments should be changed appropriately. The nomination
was approved, and r10835 is the comment fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10835 - trunk/subversion/include
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2004-09-08 at 10:42, kfogel@collab.net wrote:
> > > - * @deprecated Provided for backward compatibility with the 1.1.0 API.
> > > + * @deprecated Provided for backward compatibility with the 1.0.0 API.
>
> > Is this the right change?
>
> Of course it's the right change. We're deprecating the function in 1.1;
> it's provided for backward compatibility with 1.0.
This change was on trunk, so aren't we deprecating in 1.2?
However, bizarrely, I seem to have misread the change, even though I
looked at it several times :-(. The change *does* deprecate in
exactly the way I was suggesting it should (but thought it didn't).
> A separate question is whether the code was right before, when we
> thought we were deprecating the function in 1.2:
I don't understand this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10835 - trunk/subversion/include
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-09-08 at 10:42, kfogel@collab.net wrote:
> > - * @deprecated Provided for backward compatibility with the 1.1.0 API.
> > + * @deprecated Provided for backward compatibility with the 1.0.0 API.
> Is this the right change?
Of course it's the right change. We're deprecating the function in 1.1;
it's provided for backward compatibility with 1.0.
A separate question is whether the code was right before, when we
thought we were deprecating the function in 1.2:
> When deprecating something, we should say
> it's "provided for backward compatibility with" the earliest
> Subversion possible, since that implies all later ones anyway.
To me, it makes more sense to state the latest version in which the
function wasn't deprecated. Sure, that doesn't provide as much
information about when the function was first available, but it provides
more information about when the function was last recommended.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org