core: clean up code deprecated in 1.1#2678
Conversation
735cc32 to
7f8de7c
Compare
carl-mastrangelo
left a comment
There was a problem hiding this comment.
Unfortunately, ClientAuthInterceptor is widely used internally.
|
What's the deprecation policy then? (ie. when we're free to clean up stuff?) Also, |
|
As far as our deprecation process, we are free to delete it in 1.1 because it was deprecated in 1.0. But since we've not migrated users over to the new thing yet in our codebase we've not made sure the process is smooth. So it's easy to just leave it there for now and remove it once we're sure the next thing and process is ready. |
|
That's fair, and I don't have the intention to push for it, but wouldn't it be better to get rid of it now, and motivate users to make a switch before 1.2 will be release? (which will take some time). That'd work unless you guys aren't building against HEAD, obviously, in which case I'll revert deletion of |
7f8de7c to
276b68c
Compare
|
@ejona86 @carl-mastrangelo I've restored the |
| * @deprecated {@link Object#equals(Object)} is not supported on TolerantDeadlineComparison | ||
| * If you meant to compare deadlines, use {@link #of(Deadline)} instead. | ||
| */ | ||
| @Deprecated |
There was a problem hiding this comment.
This is actually here to scare people away from it. I think the deprecated is present to make IDEs catch on more quickly that they shouldn't be using it. The exception is to enforce it. Truth makes it easy to accidentally call:
assertAbout(DeadlineSubject.deadline()).that(myDeadline).equals(otherDeadline);
vs.
assertAbout(DeadlineSubject.deadline()).that(myDeadline).IsEqual(otherDeadline);
The first asserts that the DeadlineSubject itself is equal to the deadline, where as the latter compares the subject to the object.
There was a problem hiding this comment.
Ah, makes sense. I've added comment clarifying that.
| * | ||
| * @deprecated Use {@link #maxInboundMessageSize} instead | ||
| */ | ||
| @Deprecated |
There was a problem hiding this comment.
We still use this method internally, and while it can be removed per the compat guidelines, we wouldn't be able to sync gRPC internally. We find a fair number of issues when doing the sync, so removing this now would cause more issues than it fixes.
I am undertaking the fixing of users, but it takes time.
Add comment claryfing deprecation in DeadlineSubject
276b68c to
1ae37f1
Compare
|
@carl-mastrangelo is it okay now, in this form? |
carl-mastrangelo
left a comment
There was a problem hiding this comment.
LGTM.
@zhangkun83 Want to double check it?
Since we're on 1.2 train, we can clean this up now :)