I don't think we should be concerned with people directly extending the various metrics classes. They're not meant to be a "user API" IMO. We should annotate them as private. But the external-facing interface (ie the JMX output) should be treated as an interface.
If we have to break them at some point without a deprecation path, +1 for doing so in 0.96. On Tue, Jul 10, 2012 at 10:32 AM, Ted Yu <[email protected]> wrote: > Todd brought up a good point. > > MetricsBase class only exists in old metrics framework but not metrics2 > framework. > So I am not sure whether the actual names of (all) the metrics exposed > would be kept consistent. > > Since MetricsHistogram, etc, are public, we do need to deprecate them in > 0.94 in case some users extend these classes. > > Would listen to metrics experts' comments. > > On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon <[email protected]> wrote: > >> I think there's an important distinction between the Java API of >> metrics, and the implicit interface that the metrics themselves >> expose. IMO, we can completely change the implementation of metrics >> (e.g. class names and java APIs) so long as the actual names of the >> metrics exposed are kept consistent. If we make a change there, we >> should provide a deprecation path if at all possible - otherwise we >> need a big warning on upgrade so that operators know what they're >> getting themselves into. >> >> -Todd >> >> On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu <[email protected]> wrote: >> > There is no annotation declaring whether the current metrics are stable >> API: >> > >> > public class MetricsHistogram extends MetricsBase { >> > >> > LarsH has endorsed marking the current metrics classes deprecated in his >> > later reply to this thread. >> > >> > Correct me if my interpretation is wrong. >> > >> > On Tue, Jul 10, 2012 at 9:23 AM, Stack <[email protected]> wrote: >> > >> >> On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <[email protected]> >> >> wrote: >> >> > 0.94 is already out and did not have these deprecated. So deprecating >> >> them now in a point release is a bit strange. >> >> > Not -1'ing it, just raising that thought here. >> >> > >> >> > As said below because of HBASE-6311 0.94.1 should get out soon. If >> push >> >> comes to shuff are folks ok with: >> >> > 1. deprecating in a point release >> >> > 2. maybe doing that in 0.94.2 >> >> > ? >> >> > >> >> >> >> In the past, we'd remove public APIs after deprecating them across a >> >> full major release: i.e. we'd deprecate something we want to remove in >> >> 0.96.0 in 0.94.0 (not 0.94.1). Are the metrics changes to public >> >> "stable" APIs? If so, I'd ask why change our convention now? If >> >> they are "evolving", we might bend the rules. >> >> >> >> Regards, what goes into 0.94.1, its up to the release manager. They >> >> can entertain petitions regards what to include but ultimately its up >> >> to the RM when it happens and what is in it. >> >> >> >> St.Ack >> >> >> >> >> >> -- >> Todd Lipcon >> Software Engineer, Cloudera >> -- Todd Lipcon Software Engineer, Cloudera
