[Feature Request] Allow quering issues for "replaced" and "replacing" releases

[Lingviston]

Problem Statement

I'm working on the mobile app and we have 2 weeks release cycle. In such setup the release adoption usually looks like this:

• A new releases replaces the previous one every 2 weeks
• Neither release ever reaches 100% adoption (cause it's mobile app)
• Neither release ever reaches 0% adoption (cause it's mobile app)

As an on duty person, I'm only interested in the performance of the last 2 versions. I'm not interested in these releases, which are old and have 0.smth adoption ratio. Thus I need to be able to target only these 2 versions in the following tools:

• Discover queries
• Issues list
• Alerts

There's also a "hotfix" edge case: a version to rollout, but until it reached any big adoption ratio it is replaced with a hotfix - in this case hotfix should replace the version being fixed in all monitoring tools.

Solution Brainstorm

I thought I could use release.stage:adopted to achieve the goal. However, in case of mobile apps the problem is in that many users do not update or update very slowly. Thus there's that bottom line on the graph of dozens of versions, which have 1-3% adoption ratio, are old, will never grow anymore, but still have the release.stage:adopted status. Thus if I target it, I'll end up much more than 2 versions in the filter.

Ideally, it would be great if Sentry could detect this n-weeks release cycle and cleverly detect those "replacing" and "replaced" versions and allow to target them explicitly. If those stages could be detected, the typical version flow could be the following:

• release.stage:none
• release.stage:adopting
• release.stage:adopted
• release.stage:declining
• Some configurable adoption ratio reached
• release.stage:low_adoption

Alternatively we could use a new meta variable, smth like version:latest, version:latest-1 to be able to achieve the goal. Or release:adoption_percent >= n.

The situations is a bit different with alerts: there we can target the latest release, but not the "pre-latest" one. Also, I suppose that it simply looks at the release version number.

Product Area

Discover

[getsantry[bot]]

Assigning to @getsentry/support for routing, due by Tuesday, June 20th at 9:39 am (sfo). ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-discover for triage, due by Tuesday, June 20th at 13:11 (yyz). ⏲️

[brentc]

@Lingviston Thanks for the request. This is an interesting idea, and it's definitely an area that could be improved in the product. I'm not sure the Discover team is the right one for moving this forward though, so this might need to be re-routed.

@silent1mezzo Where should this go?

[Dhrumil-Sentry]

Alternatively we could use a new meta variable, smth like version:latest, version:latest-1 to be able to achieve the goal

@Lingviston This is a request that was asked in https://github.com/getsentry/sentry/issues/41712 as well. I will use that issue to track this request

[Lingviston]

@Dhrumil-Sentry ok. Recently, I've been also thinking that archiving all releases except of the last two, could help. However, archiving raises a ton more of questions. For example:

• What will happen with existing issues, if they only contained events from an archived release and then ongoing release starts sending the same issues as well? Will it re-open the issue or create a new one?
• What if some issues starts spiking in an archived release?

These are just the top two, which immediately raise in my head.

[getsantry[bot]]

Routing to @getsentry/product-owners-releases for triage ⏲️