releng: link to Sentry release in release notes

[dmke]

When crafting the release notes for the self-hosted project, adding a link to the Sentry project release would be beneficial for users only receiving notifications the self-hosted project.

Discussion: #2964 (comment)

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[BYK]

I'll see if we can find a better way as ideally the changelogs are fully automated. Adding these manually every time adds an unnecessary burden to the team that manages the releases.

I'll see if I can make our release tool support a scenario like this.

[dmke]

@BYK, any news?

[aldy505]

I think we won't go with this.

@dmke What do you personally think about this kind of release notes? https://github.com/getsentry/self-hosted/releases/tag/25.6.0

[dmke]

Here's my personal opinion from an ops perspective:

I want to know how much time I need to plan for an upgrade, i.e.:

• Are there important changes regarding the upgrade process?
  • Are there major updates of components, which require manual intervention (like Postgres N to N+1 would be tedious)
• Do I need to update config files?
  • Are there new knobs (env vars/config.yml/sentry.conf.py)? Did the meaning/scope of existing knobs change?
• Would I be in trouble if I run ./install.sh without reading any changelog?
  • (Of course I am, but what if may hasty colleague did already run the install script?)
• Which version of Sentry will be installed with the current release?
  • This one's fairly obvious, as the releases ought to be in sync - however that's not explicitly stated (at least not at obvious place; not to rule out that I'm blind 😛)

I don't need you to reproduce the full changelog of both getsentry/self-hosted and getsentry/sentry in the release notes, when simple links to https://github.com/getsentry/self-hosted/blob/<tag>/CHANGELOG.md and https://github.com/getsentry/sentry/blob/<tag>/CHANGES are sufficient.

OTOH, including some news (like the availability of ARM64 containers) is nice to have.

[aldy505]

Here's my personal opinion from an ops perspective:

I want to know how much time I need to plan for an upgrade, i.e.:

• Are there important changes regarding the upgrade process?

  • Are there major updates of components, which require manual intervention (like Postgres N to N+1 would be tedious)

• Do I need to update config files?

  • Are there new knobs (env vars/config.yml/sentry.conf.py)? Did the meaning/scope of existing knobs change?

• Would I be in trouble if I run ./install.sh without reading any changelog?

  • (Of course I am, but what if may hasty colleague did already run the install script?)

• Which version of Sentry will be installed with the current release?

  • This one's fairly obvious, as the releases ought to be in sync - however that's not explicitly stated (at least not at obvious place; not to rule out that I'm blind 😛)

For these kind of things, I'd say it should be on the release notes instead of the CHANGELOG.md. As I think more people read the release notes instead of the changelog.

On another note, I'll put your questions to the release notes template, I think those are great!

I don't need you to reproduce the full changelog of both getsentry/self-hosted and getsentry/sentry in the release notes, when simple links to https://github.com/getsentry/self-hosted/blob/<tag>/CHANGELOG.md and https://github.com/getsentry/sentry/blob/<tag>/CHANGES are sufficient.

But... would self-hosted and sentry would be sufficient? There are changelogs for other repository that we depends on as well: snuba, relay, symbolicator, taskbroker, and soon, uptime-checker.

I'm not against putting up a link, but I'd argue that providing human-readable release notes on what changed and what the operator should do is better. What do you think?