HBASE-22262 Removed deprecated methods from Filter class #162
Conversation
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
The test failure seems to be unrelated to the actual change. |
|
🎊 +1 overall
This message was automatically generated. |
I think 'a whole major version' just means we can not remove deprecated stuff if it is first deprecated in the same major version? For example, it is OK to remove a class in 3.0.0 if it is deprecated in 2.1.0, but you can not remove it in 2.2.0. |
|
"An API needs to be deprecated for a major version before we will change/remove it." ... in "Client API compatibility" in http://hbase.apache.org/book.html#hbase.versioning.post10 |
|
I had the same understanding as @Apache9. I know we had a discussion about this some time ago, but wasn't able to find it anymore. Probably the documentation needs some more details (an example would be good), because it is up to some kind of interpretation. I think if we deprecate something in 2.0.0 we can remove it in 3.0.0. But what about the minor versions? If we deprecated something in 2.3.0 and the next version to be released is 3.0.0 we don't really have a deprecation for a major version. Removing it in 3.3.0 also doesn't seem to be good. With that the next major version would be 4.0.0, so removing it after 1.5 major versions. |
|
My interpretation is that you have to wait at least a major version so as per your example, it'd be 4.0.0 if deprecation was added in anything after 2.0.0. |
That would be too tough? I think a major release is where we do breaking changes. And I found this in our ref guide
So I think it is OK to remove deprecated classes in a major release? We can leave it there for some reasons, but removing it is also acceptable. |
|
Sounds like we need to get clarification here. I think the 'Example' sentence is open to various interpretation. ML? |
|
I have already done some removal of deprecated classes on master... But I think your point on 'at lease a whole major release' is also valid. For example, we have deprecated something on 2.1.0, but users may upgrade to 3.0.0 from 2.0.0, so they will not see the deprecation and find out some APIs are gone... So maybe we need a guide on rolling upgrading, for example, 2.x users must upgrade to, for example, 2.3.0 first, before upgrading to 3.0.0? And we must make sure that, all classes deprecated after 2.3.0 release, must be retained until we release 4.0.0. What do you think? |
|
Lets discuss on ML. I think asking folks to rolling upgrade to the most minor version before going to next major may be an unfair expectation. |
|
Anyway we have already done lots of removal and it is not likely that we can add them back, so... |
|
Also agree to discuss it on the ML. Will create a thread later today. We definitely need to make the documentation more clear. Regarding this PR: The two methods in the |
|
💔 -1 overall
This message was automatically generated. |
|
So, we got clarification on the ML. How does it effect the patch? Thanks. |
|
@saintstack It shouldn't affect the patch, because the two methods were deprecated in 2.0.0 and with that can be removed in 3.0.0. In my opinion we're ready to merge. |
|
@HorizonNet Ok. +1 on commit sir. |
No description provided.