Meta issue: roadmap to 1.0.

[tobz]

As I've been working on metrics for nearly the last two years, things have slowed down quite a bit in terms of development of the public API of metrics. While there have been changes to Recorder, and the introduction of metric handles, and so on, the method of consumption -- the macros -- have been fairly stable. My intent was always to match the ubiquity and simplicity of crates like log and tracing: the usage side where the macros live have simple, approachable interfaces. The hard work is pushed to the underlying implementations.

With metrics, I feel comfortable with where that aspect of the library has landed. It's now time to consider formalizing that aspect, and the dependent interfaces, by working towards a 1.0 release.

Overall Plan

Practically speaking, the macros are essentially done, save for a few ergonomics improvements. The main glut of work in order to get to a 1.0 release lays with the exporter side: Recorder, Key, Label, and so on.

I'm fairly comfortable with the general approach we've taken, but there's still some outstanding problems/sharp edges that need to be dealt with, in no particular order, as part of a non-exhaustive list:

• metrics expiry (i.e. removing from registry) doesn't work with metric handles
• metric description (description and unit) are conceptually useful, but rely on fragile macros and isn't terribly flexible (what if more than unit or description are required?)
• keys can be constructed (both the name and labels) of static strings and owned strings, but less-than-'static strings are still not possible (this makes it harder to come up with solutions to caching/reducing string allocations if you can't strictly maintain only using 'static strings)

Roadmap itself

As mentioned above, those items represent the issues that are the most top-of-mind for me, but the list is definitely non-exhaustive. This issue will likely sit around for a while as I brainstorm a little more and then actually start filing issues and trying to do any work that is deemed necessary.

My vision is land a 1.0 release by March 2023 at the very latest. This puts a hard limit on how long we have to think about if we want to change anything else, as well as doing the work for it and testing it out. This means that we probably won't get 1.0 as good as we could if we had a far longer time horizon, but I'm OK with that: a lot of people seem to get value from metrics as-is, and I don't need it to be the best and only solution. I just want the people who do use it to feel good about doing so.

[hlbarber]

The smithy-rs team have been playing with metrics for some time now and I'd like to contribute some points for consideration prior to stabilization:

• Naming around counter and increment_counter can be confusing. Both counter and increment_counter can increment counters, but increment_counter only by one.
• In tracing there is a notion of "first class metadata" such as level, target, and module_path, where the target defaults to the module_path when not specified. Adding this to the macros API might improve filtering.