Why are different project release versions linked?

1

Hello,
I am trying to make sense of how the releases feature works in Sentry and noticed that, apparently, an organization is expected to have a flat versioning for all its projects?

By using sentry-cli releases list I will get a flattened version table by organization rather than a project.

Would this mean that organization/API at 1.5.0 need to be linked to organization/Front-end at 1.5.0?

I have tried to create these two versions for each project, but apparently, they are links as ‘Other projects affected’ which is not what I expected?

Considering this behaviour, it seems like projects need to keep the same versioning even though there was no relation/reason for bumping the version number on its counterpart?

I hope this makes sense.

Please let me know if my assumptions are correct and the reason behind it.

Thanks in advance.

1 Like
2

I’m struggling with understanding the reasoning behind this as well.
As far as I can see:

  • A release is linked to a project
  • A deploy is linked to a release
    Meaning, a release needs to be unique across the org, not only in the context of a project.
    So, if I have two microservices, both at version 2.0.0 I can’t use “2.0.0” as the version for both of them.

I guess it’s possible to prefix with project name in the version string, so that unique releases are created:
ServiceA-2.0.0 and ServiceB-2.0.0. but this doesn’t make much sense to me. I don’t see why this feature is designed like it is - the documentation even states that if the repo is using tagged commits, then those tags should be used. It doesn’t say anything about the potential collisions if the same tags are being used across different projects.

This also makes it much harder to link exceptions to versions, since the app needs to not only send its semantic version (2.0.0), but in addition it needs to know the “prefix” so that it can construct “ServiceA-2.0.0”.

I’d be very interested in hearing from Sentry how this is thought to work when multiple services may have overlapping versions.

1 Like
3

Digging more into this:
It looks like Sentry has some smarts to determine version from a “constructed” version when creating a release:

If I create a new release like this:
sentry-cli releases new -p flask2 "flask2--0.1.25-pr1001" --finalize, the name of the release as seen in the UI will stil be 0.1.25-pr1001 - so it looks like there’s some parsing going on, and the api separates between “version” and “shortVersion”, the latter being the parsed one. However, this doesn’t seem completely stable - sometimes shortVersion contains the parsed semver, and sometimes not. I have not succeeded in getting this reproducable.

EDIT:
Looking closer at the version parser which populates shortVersion (https://github.com/getsentry/sentry/blob/b0031df71f3655e98823df5be1f39123fd511516/src/sentry/models/release.py#L37), it looks like a separate shortversion is created if the “prefix” contains a dot, so:
flask2.flask2---2.0.9 --> 2.0.9
flask2.flask2 --> N/A
flask2 --> N/A

So it looks like it might be possible to get around all of this by prefixing the versions with the project name and making sure that the prefix contains a dot, tho I still struggle to understand why it’s designed like this.

4

I stumbled upon this issue today as well. Cause I am prefixing my release tags now with the project name and in my opinion it’s a little bit ugly. Is there any chance someone at Sentry can respond to this to explain it a little bit more?

5

Add another one to the list. Deployed a release for Project A that had the same version as Project B, and it was B that got the deploy marker on it. Haven’t tried the prefix trick, but agree with others that it’s an ugly hack.

6

Found an issue in Sentry’s GitHub that addresses this.

7

Some other related issues: