+1 for all complains. This is a “features” no one asked for, that is badly designed and confuses everyone and especially users, which is the last thing project maintainers want, and with bugs in the UI as already pointed (Release tabs shows non-Release tags), and which makes very restrictive assumptions on the use of tags. Please remove this issue from any “feature request” and log that as what it is, a bug. As the originally linked SO question shows, this has been asked for for over 4 years now.
Because tags are different from branches, despite how Sourcetree displays them. A branch is a name for some unit of work that can grow and change over time, with commits added, subtracted, or changed. A tag is a name for a specific commit, a specific point in the repository’s history. While you can delete and recreate a tag, it is not typically done. A tag is intended to be fixed.
Aside from the usual convention that tags do not change (which is just that, a convention), I think this is a misunderstanding of what git tags and branches are. (Lightweight) tags and branches are not different, they are both git refs, that is “pointers” to commits. The distinction you are making is in my opinion purely artificial; there is no concept of “unit of work” in git. The only real technical difference is that a git branch ref moves automatically when you commit on the HEAD branch, and a git tag does not. And this is merely a convenience feature so you don’t have to move it manually.
The difference one could care about here is between lightweight and annotated tags, which this time are truly different. But it is simply ignored by GitHub which by default creates lightweight tags if a Release is authored from the UI, but will also happily allow selecting an existing annotated tag manually created beforehand. Incidentally the use of lightweight tags by default for something as important as a Release point in a project, which by convention (how ironic) usually make use of annotated tags instead (see the git repository itself as an example) is rather arguable.
This doesn’t justify in my opinion forcing a GitHub Release on each tag. I can totally understand this being difficult to change, given historical assumptions and architectural constraints of the current GitHub implementation. But I find it a bit controversial to justify this GitHub-specific behavior by making wrong assumptions about how git works or how its users are using it, especially when those users have been requesting a change for the past 4 years.
I reached out to GitHub support to request a fix of this critical UX issue. I’m hoping they’ll address that quicker than this forum thread.
I have to work my GitHub Actions around that instead of using tags for dev versions and run them on new tags pushed.
me too - OMG 4 years, really to filter out something from UI
Is this really so hard to fix? Instead of one tab “Releases”, have 2 tabs, “Releases” and “Other tags”. When the repo gets tagged, ask which of the 2 tabs this new tag should be added to.
Another up vote for addressing this issue. We just uploaded a project with a long history, and was shocked to see “807” releases reported. Obviously not all of those tags are release tags. A very confusing situation - and apparently no way for the user to manually correct this.
I’ve created one phoney release whose title is “Do not download from this page, get latest master instead” (see https://github.com/aardappel/lobster/releases) just to work around the lack of this feature.
There’s a lot of people out there that think a “release” is somehow better quality or easier to install than
master, so they blindly go there to download. For a project that doesn’t do releases (yet), this is harmful, since users end up with really old versions and wonder why stuff doesn’t work, and assume the project is not worth their time.
Alternatively, if adding UI to hide tags is just too hard, add an option to hide the releases page? Or to allow the releases page to show “this project doesn’t do releases yet” instead of the tags? Anything?
Totally second this, caused some unnecessary confusion on our team as well.
We are also getting this kind of complaint, for the same reason. https://github.com/dagster-io/dagster/issues/2330
Me too, I would like this feature to be fixed!
Me too hoping for fix!!
This bit us today too. A user downloaded a zip for a very old tag because they thought it was a release. This has been an issue for over 2 years now… how about a fix @nat ?
Here’s another +1 for me. It would be great if the “Releases” tab showed just releases, and the “Tags” tab showed the tags.
Yet another request to have tags and releases be independent.
We have been using github actions to build a product.
We use a tag to kick off the build process.
NOT EVERY BUILD IS A RELEASE!
on top of this, every few builds, we get an out of space warning. We have no way to stop it from saving the source with every tag so every few builds we need to go in and delete the saved sources. So. Very. Annoying!
Another +1 on this issue.
As many others have said, not every tag should be added to the releases. There are so many purposes for tags that do not amount to a release of the project.
KLUDGE: After creating the tag, I opened the corresponding release and changed its title to be empty. This seemed to remove it from the release list while leaving it in the tag list. But this still leaves a lot of stuff lying around that looks like a release if people go digging for tag information.
I too second this. I find it a horrible decision to link tags to releases. Tags are just labels for commits, labels that could contain any sort of information. Yet GitHub acts as if tags are only used for labeling releases. I am stuck now as I need to release multiple projects from the same repository with each different versions. And for that reason I do not wish to use tags.
We don’t have CI builds or packaged releases or anything so most of this feature is useless to us. However, being able to make a note for documentation sake of when something got deployed and what changed in that update is really nice. The one thing that is preventing this feature from being 100 times more useful for us is that the tags don’t get shown in the commit history view.
Currently we make extraneous README update commits just to mark when a deploy happened. If we could see tags in the commit history view that would be way better
+1 this is a really confusing feature. At least add an option to disable it.
+1 Same problem. Lightweight tags showing up on the “Releases” List. It’s a huge problem for our users. Is there a github issue link, that we can upvote?