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 >
