Allow resolving issues with a release that doesn't exist yet

[redxdev]

Problem Statement

Our team is almost entirely based around perforce, and while I understand #68525 is unlikely to be solved any time soon, one of the problems we run into with sentry being unable to see what p4 changelists exist like it can for git commits is that we can't tell sentry when specifically an issue is resolved - at best we can say "resolved in the next release" if the fix hasn't made its way into a release sentry knows about yet.

This ends up being a pretty annoying limitation, as we don't tell sentry about releases until a build is made, and the time from submitting a change to a build being created can be a day or two, with lots of other builds happening in the meantime.

This can result in the following problem:

1. A crash is sent to sentry in release 1
2. Someone submits a fix to the issue and marks the issue as "resolved in the next release" since they can't associate it with a perforce changelist and no release has been created yet.
3. Release 2 is created from before the fix was submitted (maybe this was already a build in flight and so didn't have the fix)
4. Sentry re-activates the issue because the crash happens again, despite us knowing the fix wasn't in that build

This sequence of events happens annoyingly often, and being able to specify a specific release that doesn't exist in sentry yet would be very useful for us.

Solution Brainstorm

No response

Product Area

Issues

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[getsantry]

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

[rachrwang]

@redxdev - what would be your ideal workflow? Would it be something like "resolve in release..." and then you have an input field to type in the name of the non-existent release?

[redxdev]

@rachrwang yeah, that's exactly what I think would work here. Obviously sentry can't suggest releases it doesn't know about, but if I know the exact release name/id/whatever it is I'd like to be able to enter it.

I guess there's some pitfalls with the release potentially never getting sent to sentry, but at least when sentry is operating on a release structure it can understand (like semver) it seems like it should be able to reactivate the issue if a future release has the same error again.