Repository navigation
Conversation
…itions A release condition value that starts with >, >=, <, <= or = now compiles to Relay's semver rule condition instead of a glob, so a filter can drop data from a version range such as >=1.2.0 without listing each version as a pattern. The API rejects a comparison whose release carries no version, as Relay would never match it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Backend
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
A release value without a comparator that carries a version, such as 1.2.0 or myapp@1.2.0, now compares as equal to that version instead of matching the text. So 1.2 matches 1.2.0 of every package, and a build code does not get in the way. A value without a version, such as a commit hash or a glob, still matches the text. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
shellmayr
changed the title
Relay renamed the version comparison condition from `semver` to `release` in getsentry/relay#6430. Emit the new op so a Relay with the condition matches it, and name the types after it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The release parser raises on a value with bad characters, such as `builds/*`, or past the length limit. A glob with such a value made the custom filter endpoint fail with a 500. Relay reads no version out of these releases, so a comparison against one is rejected like one against a commit hash, and a glob stays a glob. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The Relay config test that master added expects a glob for the release value 1.2.3. On this branch a plain version compares as equal through the release condition, so the test expects that condition instead. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
vgrozdanic
approved these changes
Oct 15, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
releaserule condition, added in feat(generic-filters): Add a release rule condition relay#6430. That is a value with a leading>,>=,<,<=or=, or a plain release with a version such as1.2.0ormyapp@1.2.0, which compares as equal. Any other value stays a glob pattern, so one condition can mix1.*with>=3.0.>2*or<a4b7e0f9c2d1. Relay would never match those, so the filter would silently lose part of its values.releaseop reads the condition as unsupported and never matches it. Such a filter drops nothing instead of dropping more than configured.builds/*or one past the length limit, stays a glob. A comparison against one is rejected like one against a commit hash. Before, the endpoint failed with a 500 on such a value.