Thanks for doing this work LukeWinikates. While I agree that we should eventually delete deprecated APIs, we may have several clients that still use these deprecated APIs. I have solicited other team members to have a look.

Thanks @keep94 - I definitely understand the concern.

Here's why I think removing the APIs is reasonable:

• it doesn't immediately break anybody's code - they have to intentionally update their dependencies in order to get a new version of the sdk.
• unless the APIs are removed, there's not much incentive for users to stop using old API calls.
• by convention, a pre 1.0 API makes no compatibility guarantees

Thanks for getting more team members looking at these changes. Curious to hear what others think.

@LukeWinikates thanks for helping to move this forward.

@keep94 now that we have a release that has properly deprecated the Direct and Proxy senders, I think we're good to make a new release that actually deletes them. I think this warrants bumping to v0.11.0 as well. Thoughts?

Let me know if y'all want me to rebase this branch to resolve the merge conflicts. I'm also fine if one of y'all wants to rebase it so that you can close the issue sooner.

Some docs changes that go along with this :

• Update the README to reference the single, unified sender, but call out proxy vs direct ingestion config. Also update https://github.com/wavefrontHQ/wavefront-sdk-doc-sources/tree/master/go.
• Document the internal metrics (~sdk. prefix) in the README with a new section titled "Monitor the SDK." Certain ones from the deleted Proxy Sender are no longer valid and are gone altogether. For reference on an existing way we document internal metrics for the Java SDK, see https://github.com/wavefrontHQ/wavefront-sdk-doc-sources/blob/master/java/internalmetrics.md
• Consider adding an example in the golang format so it shows up in pkg.go.dev. If appropropriate, delete the examples from the README and just link to pkg.go.dev.

@LukeWinikates Thank you again for the hard work. oppegard and I agree that we should merge this PR and delete the old deprecated APIs. It is fine if you rebase to resolve the conflicts with master. I was talking to oppegard saying it might be cool to add GO style examples that show up in pkg.go.dev and have the README file link to those examples. The advantage of GO style examples is that they get compiled and ran as part of the test suite, so you can be confident that they are correct. Also the examples show up in pkg.go.dev which is where GO developers go to learn how to use new APIs. You can read all about GO examples here https://go.dev/blog/examples. Would you be interested in doing that work? We could make the example work a different PR if you'd like.

Thanks @keep94 - I'll rebase this tomorrow. I'll also add the examples as you described. I think that's a great idea.

@oppegard thanks for you comments - I'll look into those as well

I rebased the commit, but I'm also finding a lot to digest about the docs.

1. I like the idea of the go examples, but it's more subtle than I realized. I am thinking to update the README for this commit and create a new draft commit where we could talk through the go examples. Since there are quite a few examples in the README, I wonder if we should put all of them into golang examples. But at the same time, since we are documenting something that does network IO, I'm not sure how reasonable it is to give complete examples that can run as part of the test suite. Maybe if we run an in-process http server?

2. Since wavefront-sdk-doc-sources seems to copy-paste a lot of README content from this repository... should we consider something like submoduling so that we can automate the duplication? Or alternatively maybe that repo doesn't need to exist in the longer term? (I'm not sure if it's used to generate html documentation or something like that)

3. I think that for generating the ~sdk metrics, I'd like to create another issue for tracking that one. My proposal is that we refactor that instrumentation code to make it a bit easier to emit the metrics list based on the code, but that's too much for this PR.

@oppegard & @keep94 I'd like to hear your thoughts on the above. In the meantime, here's my checklist:

• update the README in this repo
• add basic code examples for wavefront.NewSender

Once this PR is approved, I'll copy the README content over into wavefront-sdk-doc-sources as well

@LukeWinikates Regarding your point number 1. If you have "output" comments immediately following your example code such as

// Output:
// Hello world

Then GO runs your example code to verify that the output produced matches the expected output. But I have never written a go example without expected output. Maybe if there is no expected output, GO won't run the example at all only compile it? I'll do some experimenting around this today.

I am not sure about your second point yet. I don't know enough about wavefront-sdk-doc-sources to have an opinion.

As for point number 3, while automating the generation of the internal metrics documentation would be cool. I don't think the internal metric names will change much in the future. Therefore, I think it is enough to just hand document the internal metrics the normal way.

@LukeWinikates I just confirmed by experiment that examples in GO without documented expected output are only compiled and not ran. So having example code that opens http connections should be fine as long as there is no documented expected output. That is no

// Output:
// Hello world

comments exist after the code

As for point number 3, while automating the generation of the internal metrics documentation would be cool. I don't think the internal metric names will change much in the future. Therefore, I think it is enough to just hand document the internal metrics the normal way.

That's fair - I still think that the internal metrics aren't related to the purpose of this PR, and it would be better to open another issue to track that.

That's fair - I still think that the internal metrics aren't related to the purpose of this PR, and it would be better to open another issue to track that.

That's also fair regarding internal metrics. I've created a 1.0.0 Milestone, and will create a new issue about documenting internal metrics that's tagged to that milestone.

@oppegard @keep94 I think this is ready to go now.

I added a Makefile with a make test target, with the thought that Makefiles are pretty idiomatic in go, and this could also be used to automate some of the release-related tasks moving forward. Let me know if you'd prefer not to merge that as part of this PR.

regarding wavefront-sdk-doc-sources, I did open this issue: wavefrontHQ/wavefront-sdk-doc-sources#13

Because I am skeptical of the value created by that repository given the overhead of maintaining it, and its apparent staleness.