Sentry: Improve release tracking setup instructions

[dcramer]

Often people get confused that they need to both (or at least) configure their app, as well as configure the push endpoint. To quote a recent support ticket:

Didn't even realize the first box was something that had to be done. I assume (just by the UX/UI) that each "box" was a different way to do release tracking. Could be interesting/useful to make that first box a different color. Or put numbered steps above each sector.

The other bit of feedback is that we don't strongly say "use the full SHA from your VCS for the version". Some people have strong release processes where they dont want that, but we should educate people on the better default.

@getsentry/ui

[mastacheata]

My problem with the first box was a somewhat different one:
In the third box you make it obvious that the release value should match your release identifier, but in the first box it looks more like this was some static sentry-identifier and the release was then applied automatically based on time. (Yeah, that's not how it works and wouldn't be a good idea anyways, but it's how I understood it)

[akramShokri]

@dcramer
In release tracking instruction, the only client setup guide which is provided is for raven. I am using a custom class in android to send logs to a self-hosted sentry server. I can not find out how should I send the release value to server. In brief, I need to know whether I should put it in extera or tag part of generated Json? (or somewhere else?)

[dcramer]

@akramShokri we document our SDK on docs.getsentry.com (under Client API): https://docs.getsentry.com/hosted/clientdev/attributes/

The short answer is its the 'release' tag

[faceleg]

In the third box you make it obvious that the release value should match your release identifier, but in the first box it looks more like this was some static sentry-identifier and the release was then applied automatically based on time. (Yeah, that's not how it works and wouldn't be a good idea anyways, but it's how I understood it)

This was not immediately obvious to me either.

The only reason I realised I had to modify

// See SDK documentation for language specific usage.
Raven.config('your dsn', {
  release: '0e4fdef81448dcfa0e16ecc4433ff3997aa53572'
});

Is because "I got a bad feeling" and googled it, which got me here.

[rdohms]

Wait, i'm so very confused.
If i tag releases using API, Sentry does not automatically track that error happened after/before the release? I have to actively tell it which version is running?

This is so very poorly communicated if that is the case.

[mattrobenolt]

@rdohms That's correct. Just because you've tagged a release in our API does not mean that's the version of code you're running. In any system with more than 1 server, there will always be a mixed state. Even with JavaScript if someone hasn't reloaded and gotten new version of code.

So we require that the SDK is paired up to match with a release on our side so we can handle these overlapping versions. That way the release metadata is always correctly bound to the correct version of your code.

[BYK]

Closing this issue due to staleness. Feel free to comment here if you think we should still work on this.