If we want to refactor the metrics system, I think we may have to incur breaking changes. We can make it backward compatible but this means we may build an adapt layer on top of metrics, or a lot of "if...else..." which might be ugly, either way, it might be a pain to maintain the code. So I prefer to making breaking changes if we want to build a new metrics system, and I'm OK to move JStorm metrics migration phase forward to 1.x, and I'm happy to share our design & experiences.
On Thu, May 19, 2016 at 11:12 AM, Jungtaek Lim <kabh...@gmail.com> wrote: > Hi devs, > > I'd like to see our opinions on breaking changes on metrics for 1.x. > > Some backgrounds here: > > - As you may have seen, I'm trying to address some places to improve > metrics without breaking backward compatibility, but it's limited due to > interface IMetric which is opened to public. > - We're working on Storm 2.0.0, and evaluation / adoption for metrics > feature of JStorm is planned to phase 2 but we all don't know estimated > release date, and I feel it's not near future. > - We've just released Storm 1.0.x, so I expected the lifetime of Storm 1.0 > (even 0.9) months or even years. > > If someone wants to know what exactly things current metrics feature > matter, please let me know so that I will summarize. > > I have other ideas on mind to relieve some problems with current metrics, > so I'm also OK to postpone renewal of metrics to 2.0.0 with applying those > workaround ideas. But if we're having willingness to address metrics on > 1.x, IMO we can consider breaking backward compatibility from 1.x for once. > > What do you think? > > Thanks, > Jungtaek Lim (HeartSaVioR) >
