github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-17 05:36:16 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #9032] release information is chaotic #31636

New Issue
Open
opened 2026-04-22 12:17:08 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-22 12:17:08 -05:00
Owner
Copy Link

Originally created by @FlorinAndrei on GitHub (Feb 12, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/9032

What is the issue?

The main project's GitHub page claims the latest release is v0.5.7.

The Releases page lists v0.5.8 and v0.5.9. Those version numbers do not differ in any way from the preceding version numbers, it's the same pattern. Yet they are tagged differently.

If I subscribe to this project's releases (click the down arrow on the Watch button, then Custom, then Releases) I get notified by all these version numbers.

If I download the Ollama installer, there is no clue as to its version number if I just look at the file name. I have to actually start the installer to realize it's still v0.5.7.

Folks, you are unlike 99% of the GitHub projects out there when it comes to how you handle releases. Could you please put someone in the driver's seat, and figure out a less confused (and confusing) way to label and number your releases?

Thanks.

Relevant log output

OS

No response

GPU

No response

CPU

No response

Ollama version

No response

Originally created by @FlorinAndrei on GitHub (Feb 12, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/9032 ### What is the issue? The main project's GitHub page claims the latest release is v0.5.7. The Releases page lists v0.5.8 and v0.5.9. Those version numbers do not differ in any way from the preceding version numbers, it's the same pattern. Yet they are tagged differently. If I subscribe to this project's releases (click the down arrow on the Watch button, then Custom, then Releases) I get notified by all these version numbers. If I download the Ollama installer, there is no clue as to its version number if I just look at the file name. I have to actually start the installer to realize it's still v0.5.7. Folks, you are unlike 99% of the GitHub projects out there when it comes to how you handle releases. Could you please put someone in the driver's seat, and figure out a less confused (and confusing) way to label and number your releases? Thanks. ### Relevant log output ```shell ``` ### OS _No response_ ### GPU _No response_ ### CPU _No response_ ### Ollama version _No response_
GiteaMirror added the bug label 2026-04-22 12:17:08 -05:00
GiteaMirror commented 2026-04-22 12:17:09 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Feb 12, 2025):

Hey @FlorinAndrei sorry this is confusing. 0.5.7 is the current release. 0.5.8 and 0.5.9 are in "pre-release" (you should be able to see this on the releases page); 0.5.8 would have been the next release, but we found a bug in it hence the newer 0.5.9. That release is imminent.

<!-- gh-comment-id:2654958982 --> @pdevine commented on GitHub (Feb 12, 2025): Hey @FlorinAndrei sorry this is confusing. `0.5.7` is the current release. `0.5.8` and `0.5.9` are in "pre-release" (you should be able to see this on the releases page); `0.5.8` _would_ have been the next release, but we found a bug in it hence the newer `0.5.9`. That release is imminent.
GiteaMirror commented 2026-04-22 12:17:10 -05:00
Author
Owner
Copy Link

@FlorinAndrei commented on GitHub (Feb 14, 2025):

@pdevine Would be nice if you could make a sharper distinction between pre-releases and actual releases. That would prevent people from rushing to download your app, only to realize it's the same old same old. I was a little miffed when I posted this because re-installing the same old version launched me into a recursive path of breaking and fixing things. I apologize for the abrasive tone.

Have a -pre-XXXXXXX suffix in the version string, or something.

If you put a prominent -pre-YYYYMMDD-NN suffix in it (or something along those lines), and it does show in the GitHub notifications, then folks like me (only interested in stable releases) will just glide over it, whereas early adopters will know exactly they're getting the early bird stuff they want. I'm looking now at my new notifications in GH and I see projects doing exactly this. Makes it very clear what's going on. Here's an example, scroll down through it:

https://github.com/gruntwork-io/terragrunt/releases

<!-- gh-comment-id:2659918969 --> @FlorinAndrei commented on GitHub (Feb 14, 2025): @pdevine Would be nice if you could make a sharper distinction between pre-releases and actual releases. That would prevent people from rushing to download your app, only to realize it's the same old same old. I was a little miffed when I posted this because re-installing the same old version launched me into a recursive path of breaking and fixing things. I apologize for the abrasive tone. Have a `-pre-XXXXXXX` suffix in the version string, or something. If you put a prominent `-pre-YYYYMMDD-NN` suffix in it (or something along those lines), and it does show in the GitHub notifications, then folks like me (only interested in stable releases) will just glide over it, whereas early adopters will know exactly they're getting the early bird stuff they want. I'm looking now at my new notifications in GH and I see projects doing exactly this. Makes it _very clear_ what's going on. Here's an example, scroll down through it: https://github.com/gruntwork-io/terragrunt/releases
GiteaMirror commented 2026-04-22 12:17:11 -05:00
Author
Owner
Copy Link

@pdevine commented on GitHub (Feb 14, 2025):

cc @jmorganca

<!-- gh-comment-id:2660057641 --> @pdevine commented on GitHub (Feb 14, 2025): cc @jmorganca
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#31636
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?