You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2015/06/26 19:51:42 UTC
Semantic Versioning Worksheet
(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
Re: Semantic Versioning Worksheet
Posted by Andrew Purtell <ap...@apache.org>.
Wrt evolving, I would like it to mean, at least, that we can add new
methods to patch releases. Add only.
On Sunday, June 28, 2015, Sean Busbey <bu...@cloudera.com> wrote:
> On Jun 28, 2015 2:01 AM, "Mikhail Antonov" <olorinbant@gmail.com
> <javascript:;>> wrote:
> >
> > >>> The change of HTable from public/stable to private/stable is abrupt
> without a transition through deprecation.
> >
> > I actually missed this part, looked at branch-1.0 but no further
> > behind. Then we may want to keep it longer.. I'm fine either way.
> >
>
> Let's just add a note not to break it in 1.y. That should be enough
> transition time.
>
> > >>> There is none. If Private, semvar does not apply; no deprecation
> cycle necessary.
> > Given that case with abrupt transition of HTable, wondering if we want
> > to restrict transitioning from public to private, so it's not used as
> > a loophole :)
> >
>
> We already only allow public -> private on major. We should be doing a
> @deprecation beforehand, but I think 1.0 was handled as a special case
> since it was "the start".
>
> As an aside, private -> public should only happen on minor, since it adds
> to the API.
>
> > >>> What to do about Public/Evolving. semvar applies here?
> > When we introduce new client facing features, do we first mark them
> > public/evolving, and then promote to public/stable after every detail
> > settles down and get polished? Thinking out loud, I'd say -
> > public/evolving would comply with semver, except maybe that adding new
> > backward-compatible functionality in patch release is ok too. This may
> > allow us to faster absorb users' feedback on experimental things?
> >
>
> Currently, the evolving tag says that we can break compat on minor release.
> Personally, I don't care for this exception. I'd prefer it just indicate
> how likely to add to or break an API we are. (Or maybe allow removal
> without deprecation on major)
>
> I'm opposed to any weakening of the restrictions on patch releases, because
> they should be as low risk as possible.
>
> --
> Sean
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Semantic Versioning Worksheet
Posted by Stack <st...@duboce.net>.
On Sun, Jun 28, 2015 at 6:32 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Jun 28, 2015 2:01 AM, "Mikhail Antonov" <ol...@gmail.com> wrote:
> >
> > >>> The change of HTable from public/stable to private/stable is abrupt
> without a transition through deprecation.
> >
> > I actually missed this part, looked at branch-1.0 but no further
> > behind. Then we may want to keep it longer.. I'm fine either way.
> >
>
> Let's just add a note not to break it in 1.y. That should be enough
> transition time.
>
>
Ok. HBASE-13983
Thanks for the input,
St.Ack
> > >>> There is none. If Private, semvar does not apply; no deprecation
> cycle necessary.
> > Given that case with abrupt transition of HTable, wondering if we want
> > to restrict transitioning from public to private, so it's not used as
> > a loophole :)
> >
>
> We already only allow public -> private on major. We should be doing a
> @deprecation beforehand, but I think 1.0 was handled as a special case
> since it was "the start".
>
> As an aside, private -> public should only happen on minor, since it adds
> to the API.
>
> > >>> What to do about Public/Evolving. semvar applies here?
> > When we introduce new client facing features, do we first mark them
> > public/evolving, and then promote to public/stable after every detail
> > settles down and get polished? Thinking out loud, I'd say -
> > public/evolving would comply with semver, except maybe that adding new
> > backward-compatible functionality in patch release is ok too. This may
> > allow us to faster absorb users' feedback on experimental things?
> >
>
> Currently, the evolving tag says that we can break compat on minor release.
> Personally, I don't care for this exception. I'd prefer it just indicate
> how likely to add to or break an API we are. (Or maybe allow removal
> without deprecation on major)
>
> I'm opposed to any weakening of the restrictions on patch releases, because
> they should be as low risk as possible.
>
> --
> Sean
>
Re: Semantic Versioning Worksheet
Posted by Sean Busbey <bu...@cloudera.com>.
On Jun 28, 2015 2:01 AM, "Mikhail Antonov" <ol...@gmail.com> wrote:
>
> >>> The change of HTable from public/stable to private/stable is abrupt
without a transition through deprecation.
>
> I actually missed this part, looked at branch-1.0 but no further
> behind. Then we may want to keep it longer.. I'm fine either way.
>
Let's just add a note not to break it in 1.y. That should be enough
transition time.
> >>> There is none. If Private, semvar does not apply; no deprecation
cycle necessary.
> Given that case with abrupt transition of HTable, wondering if we want
> to restrict transitioning from public to private, so it's not used as
> a loophole :)
>
We already only allow public -> private on major. We should be doing a
@deprecation beforehand, but I think 1.0 was handled as a special case
since it was "the start".
As an aside, private -> public should only happen on minor, since it adds
to the API.
> >>> What to do about Public/Evolving. semvar applies here?
> When we introduce new client facing features, do we first mark them
> public/evolving, and then promote to public/stable after every detail
> settles down and get polished? Thinking out loud, I'd say -
> public/evolving would comply with semver, except maybe that adding new
> backward-compatible functionality in patch release is ok too. This may
> allow us to faster absorb users' feedback on experimental things?
>
Currently, the evolving tag says that we can break compat on minor release.
Personally, I don't care for this exception. I'd prefer it just indicate
how likely to add to or break an API we are. (Or maybe allow removal
without deprecation on major)
I'm opposed to any weakening of the restrictions on patch releases, because
they should be as low risk as possible.
--
Sean
Re: Semantic Versioning Worksheet
Posted by Mikhail Antonov <ol...@gmail.com>.
>>> The change of HTable from public/stable to private/stable is abrupt without a transition through deprecation.
I actually missed this part, looked at branch-1.0 but no further
behind. Then we may want to keep it longer.. I'm fine either way.
>>> There is none. If Private, semvar does not apply; no deprecation cycle necessary.
Given that case with abrupt transition of HTable, wondering if we want
to restrict transitioning from public to private, so it's not used as
a loophole :)
>>> What to do about Public/Evolving. semvar applies here?
When we introduce new client facing features, do we first mark them
public/evolving, and then promote to public/stable after every detail
settles down and get polished? Thinking out loud, I'd say -
public/evolving would comply with semver, except maybe that adding new
backward-compatible functionality in patch release is ok too. This may
allow us to faster absorb users' feedback on experimental things?
-Mikhail
On Sat, Jun 27, 2015 at 10:50 PM, Stack <st...@duboce.net> wrote:
> On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <ol...@gmail.com>
> wrote:
>
>> 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.
>
>
> That is pretty clear. I'm sure no one reads it but it is very explicit.
>
>
>
>> Otherwise, IMO,
>> having to go thru full major version of deprecation kind of makes
>> Private audience annotation meaningless?
>>
>>
> As you are point out later, they are not connected. The change of HTable
> from public/stable to private/stable is abrupt without a transition through
> deprecation.
>
>
>
>> 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."
>>
>>
>
> We are talking about a couple of methods; the getStartKeys and getEndKeys
> that are in HTable (The methods are moved to RegionLocator).
>
> Between the class comment and the semvar quote, IMO, it is coverage enough
> for our removing these few methods in 2.0.
>
> Speak up if you disagree.
>
> Thanks,
> St.Ack
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> -Mikhail
>>
>> On Fri, Jun 26, 2015 at 11:20 AM, Sean Busbey <bu...@cloudera.com> 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" <st...@duboce.net> 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
>>
--
Thanks,
Michael Antonov
Re: Semantic Versioning Worksheet
Posted by Stack <st...@duboce.net>.
On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <ol...@gmail.com>
wrote:
> 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.
That is pretty clear. I'm sure no one reads it but it is very explicit.
> Otherwise, IMO,
> having to go thru full major version of deprecation kind of makes
> Private audience annotation meaningless?
>
>
As you are point out later, they are not connected. The change of HTable
from public/stable to private/stable is abrupt without a transition through
deprecation.
> 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."
>
>
We are talking about a couple of methods; the getStartKeys and getEndKeys
that are in HTable (The methods are moved to RegionLocator).
Between the class comment and the semvar quote, IMO, it is coverage enough
for our removing these few methods in 2.0.
Speak up if you disagree.
Thanks,
St.Ack
>
> -Mikhail
>
> On Fri, Jun 26, 2015 at 11:20 AM, Sean Busbey <bu...@cloudera.com> 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" <st...@duboce.net> 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
>
Re: Semantic Versioning Worksheet
Posted by Stack <st...@duboce.net>.
On Fri, Jun 26, 2015 at 12:43 PM, Mikhail Antonov <ol...@gmail.com>
wrote:
> Thinking more on that.. What's the correlation between Public/Private
> annotations and Deprecated annotation? I'm not sure SemVer has notion
> of deprecation of non-public API. Should we say that we don't have it
> too, or we do, but deprecation cycle of such API is more aggressive
> than for public?
>
>
There is none. If Private, semvar does not apply; no deprecation cycle
necessary. What to do about Public/Evolving. semvar applies here?
St.Ack
> -Mikhail
>
> On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <ol...@gmail.com>
> wrote:
> > 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 <bu...@cloudera.com>
> 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" <st...@duboce.net> 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
>
>
>
> --
> Thanks,
> Michael Antonov
>
Re: Semantic Versioning Worksheet
Posted by Mikhail Antonov <ol...@gmail.com>.
Thinking more on that.. What's the correlation between Public/Private
annotations and Deprecated annotation? I'm not sure SemVer has notion
of deprecation of non-public API. Should we say that we don't have it
too, or we do, but deprecation cycle of such API is more aggressive
than for public?
-Mikhail
On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <ol...@gmail.com> wrote:
> 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 <bu...@cloudera.com> 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" <st...@duboce.net> 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
--
Thanks,
Michael Antonov
Re: Semantic Versioning Worksheet
Posted by Mikhail Antonov <ol...@gmail.com>.
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 <bu...@cloudera.com> 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" <st...@duboce.net> 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
Re: Semantic Versioning Worksheet
Posted by Stack <st...@duboce.net>.
On Fri, Jun 26, 2015 at 11:20 AM, Sean Busbey <bu...@cloudera.com> 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?
>
That is correct. It is public stable in 0.98 and then private in 1.0. We
missed deprecating a few methods in 1.0.
Stack
>
> --
> Sean
> On Jun 26, 2015 12:59 PM, "Stack" <st...@duboce.net> 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
> >
Re: Semantic Versioning Worksheet
Posted by Sean Busbey <bu...@cloudera.com>.
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" <st...@duboce.net> 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
>