Just as an aside, the original link you included in the issue description was the tag badge which was a little confusing.

However, it's true that the tag name is used for the release badge as well:

https://img.shields.io/github/v/release/gooddata/gooddata-java

https://github.com/gooddata/gooddata-java/releases/tag/gooddata-java-parent-3.7.0%2Bapi3

It seems quite reasonable to me that we provide support for using the release name for the release version badge. However, given the current state and backwards compatibility concerns there's a chance we may indeed need to make this an option controllable via query param.

cc @badges/shields-maintainers for any other thoughts

It seems quite reasonable to me that we provide support for using the release name for the release version badge. However, given the current state and backwards compatibility concerns there's a chance we may indeed need to make this an option controllable via query param.

Agreed. I think given it has worked this way for so long we would need to keep the default as it is and make it a query param

In what situation would the tag name be different from the release name? I know it's a behavior change, and probably a very small set of users will think this is a negative breaking change. Though using the release name seems like a better default, and arguably more correct. Maybe it's worth trying it for a couple weeks, and keeping it if we don't get a massive number of complaints?

In what situation would the tag name be different from the release name?

The example given is this release https://github.com/gooddata/gooddata-java/releases/tag/gooddata-java-parent-3.7.0%2Bapi3
tag: gooddata-java-parent-3.7.0+api3
release name: 3.7.0+api3

I guess I'm trying to think of a case where a developer has chosen to use a different name for the release and the tag, but wouldn't want the name they've chosen to appear on the badge. Of course we don't know all the reasons people might choose to do this, though it seems like:

• It's unusual and uncommon to choose a release name that differs from the tag name.
• Most developers who choose a different release name actually do want to highlight that name in place of the tag name.

Most developers who choose a different release name actually do want to highlight that name in place of the tag name.

I think this is likely a reasonable assumption, but the question for me is what's our degree of confidence in this. It's certainly possible that folks have been giving wildly divergent names to their Releases and relying on the current behavior to display the tag, and if that's the case then changing the message on them out of the blue could be a bit shocking.

IMO the tradeoff here really is: would we rather potentially impact existing users or have another query parameter to maintain long term (because once we add it I don't think we'll be able to drop it)

So I've just been having a look at how releases work. I rarely use them myself tbh as I don't maintain any projects which publish binary assets (which are where releases are really useful IMO). I just push tags. I found it hard to believe that this has been the behaviour since 2014 and this is the first time it has come up if what we're relying on for that hypothesis is everyone manually fills in their name field exactly the same as the tag every time. It seems unlikely that everyone is doing that completely consistently.

Interestingly, name (or "Release title" in the front-end) is not actually a required field for releases - only tag_name is, which I guess is why we're using it - we can rely on it to be populated. See
https://docs.github.com/en/rest/reference/repos#create-a-release--parameters

so I guess actually the common case is not so much that name === tag_name but more likely that name === "". I suspect that is why this hasn't come up before. Either way, name might not exist so we would want:

release.name !== "" ? release.name : release.tag_name

My initial instinct was put this behind a flag given how widely used the badge is and how long tag_name has been the default behaviour but having done the research, explicitly specifying a name or ("Release title") when you don't have to seems a fairly clear signal of intent. I think I'd be game to make the default release.name !== "" ? release.name : release.tag_name and see what happens..

I think I'd be game to make the default release.name !== "" ? release.name : release.tag_name and see what happens..

That'll work for me too. Good news is that doesn't necessarily lock us into anything either if there turns out to be any issues

I came here to report a bug, only to discover that it was a deliberate change in #6879. Depending on how your users use the "release title" field when they create releases, this is very much a breaking change. Some simply duplicate the tag in that field. But others put more descriptive titles. For example, currently, I currently put the name of the package, or action, etc, which is often the name of the repo, as well as the version tag. So now all of my release badges that previously were concise listing only the version have become cluttered with a redundant listing of the name of the repo (as well as the version number). This is assuming that I remembered to include the version number when I entered a title for the release. I now have approximately 20-25 repos that need README updates. Here are a few examples:

The tag badge may or may not be a relevant replacement for a user who just wants the version tag associated with the release in the badge because tags can be used for reasons other than releases as well.

Thank you for sharing @cicirello, this was the type of scenario I was worried about. We'll discuss and provide an update on next steps

I came here to report a bug, only to discover that it was a deliberate change in #6879. Depending on how your users use the "release title" field when they create releases, this is very much a breaking change. Some simply duplicate the tag in that field. But others put more descriptive titles. For example, currently, I currently put the name of the package, or action, etc, which is often the name of the repo, as well as the version tag. So now all of my release badges that previously were concise listing only the version have become cluttered with a redundant listing of the name of the repo (as well as the version number). This is assuming that I remembered to include the version number when I entered a title for the release. I now have approximately 20-25 repos that need README updates. Here are a few examples:

The tag badge may or may not be a relevant replacement for a user who just wants the version tag associated with the release in the badge because tags can be used for reasons other than releases as well.

The same goes here. We have a dashboard to show information about each module (of Ballerina Standard Library). This is now showing redundant information and also shrank the other columns.

I understand the logic behind using the release title instead of the tag, but I think there should be a way to switch between the tag and the title.

OK. So we've tried it and got some feedback.

I'm going to re-open this issue and pin it so it is easy to find if others want to comment.

I've submitted PR #6880 reverting a4c93c5 . We can merge/deploy that once another maintainer has approved it.

One thing I realise now from reading @ThisaruGuruge 's comment is that switching to /tag isn't necessarily a drop in replacement for the previous /release behaviour (displaying tag_name instead of name) in all cases because tags are a superset of releases. So even if we decide changing the default is the right thing to do (accepting there will be a non-zero number of users who have to update READMEs to account for it) rather than retaining the existing default and putting this option behind a flag, we probably would at least need to provide a flag to explicitly request the old/existing behaviour.

Have merged and deployed #6880, so back to where we were a couple days ago