mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
81f71cba62
In order for Sentry to parse our releases as semver, they need to be in the form of `package@version` [0]. Without this, the feature of "Mark this issue as resolved in the _next_ version" doesn't work properly because Sentry compares the versions as to when it first saw them vs parsing the semver string itself. We test versions prior to releasing them, meaning Sentry learns about a 1.4.0 version before it is actually released. This causes false-positive "regressions" even though they are fixed in a later (as per semver) release. This create some redundancy with the different DSNs that we are already using. I think it would make sense to consider merging the two projects we have for the GUI client for example. That is really just one project that happens to run as two binaries. For all other projects, I think the separation still makes sense because we e.g. may add Sentry to the "host" applications of Android and MacOS/iOS as well. For those, we would reuse the DSN and thus funnel the issues into the same Sentry project. As per Sentry's docs, releases are organisation-wide and therefore need a package identifier to be grouped correctly. [0]: https://docs.sentry.io/platforms/javascript/configuration/releases/#bind-the-version