In branch-1.0 HTable is {Private, Stable} with comment -
* <p>HTable is no longer a client API. Use {@link Table} instead. It is marked
* InterfaceAudience.Private indicating that this is an HBase-internal
class as defined in
* <a
href="https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/InterfaceClassification.html";>Hadoop
* Interface Classification</a>
* There are no guarantees for backwards source / binary compatibility
and methods or class can
* change or go away without deprecation.
So I think it's OK to remove such methods in 2.0. Otherwise, IMO,
having to go thru full major version of deprecation kind of makes
Private audience annotation meaningless?
semver.org says:
"Software using Semantic Versioning MUST declare a public API. This
API could be declared in the code itself or exist strictly in
documentation. However it is done, it should be precise and
comprehensive.
..<skipped>
Version 1.0.0 defines the public API. The way in which the version
number is incremented after this release is dependent on this public
API and how it changes."
-Mikhail
On Fri, Jun 26, 2015 at 11:20 AM, Sean Busbey <[email protected]> wrote:
> For a given major version, we should make sure to keep at least the promise
> we made when it started.
>
> For HBase 1.y, we said at 1.0 that we wouldn't remove public API without
> having a full major version of deprecation. If only for that reason I agree
> wholeheartedly on the principle.
>
> But I thought HTable wasn't public API as of the 1.0 release. Is that not
> correct?
>
> --
> Sean
> On Jun 26, 2015 12:59 PM, "Stack" <[email protected]> wrote:
>
>> (Intent is that this is a long-lived thread where we work out our
>> transition to semantic versioning).
>>
>> In HBASE-13214 "Remove deprecated and unused methods from HTable class",
>> Ashish Singhi is doing nice cleanup work. His patch is removing deprecated
>> methods from HTable for hbase-2.0.0. A few methods up for removal are
>> deprecated in hbase-1.1.0 but not in hbase-1.0.0. Ashish quotes Semantic
>> Versioning:
>>
>> "...issue a new minor release with the deprecation in place. Before you
>> completely remove the functionality in a new major release there should be
>> at least one minor release that contains the deprecation so that users can
>> smoothly transition to the new API."
>>
>> So, Ashish's patch is well within what SV allows but to my mind we need to
>> be even more conservative if only during this period of transition to SV. I
>> think we should not remove deprecated methods, especially high-profile
>> client-facing ones, until a major version has elapsed with the method
>> deprecated.
>>
>> Opinions?
>> Thanks,
>> St.Ack
>>
--
Thanks,
Michael Antonov
