Description
Did you check the docs?
- I have read all the lazy.nvim docs
Is your feature request related to a problem? Please describe.
If you use e.g. version = "^0.1", there isn't an easy way to tell when there's a new version that isn't part of the range (e.g. v0.2 or v1). With check_pinned you can see that there are commits after the version you're on, but because of this being so noisy (just because there are commits you're not on doesn't mean there's a version to update to and you're almost always going to be behind since you're using a tag), you end up ignoring the "outdated" list and just update whenever you see an update that fits into your range (e.g. v0.1.1 or a commit for a plugin you don't use version for).
Describe the solution you'd like
It would be great if there was a way to differentiate between a new commit being available for a plugin that uses version that you aren't going to update to and when a new version has been released that doesn't fit into your range. It also seems almost unintentional that check_pinned shows new commits since you intentionally used a version range and I would expect the option to instead show the plugin as outdated only when a version has been released that isn't part of your set range.
For example, if you use a plugin and set version = "^0.1" and it releases v0.1.1, you can update to it and this flow works great already.
If you've updated to v0.1.1 and a new commit is pushed that isn't part of a tag yet, it shows as outdated. If this was the intention behind check_pinned then this can just be ignored, especially if this FR would add another option and you could just not set check_pinned anymore to reduce noise.
If the plugin releases v0.2.0, you don't have a great way of knowing. It would be great if there was an option similar to check_pinned that showed a section for plugins that are updated to the latest version in its range, but there are now versions outside of its range that you aren't updating to, so you know to bump version, check for breaking changes, update your config if needed and update.
Describe alternatives you've considered
- You can just keep checking for new releases manually e.g. on GitHub which isn't great
- You can use
check_pinnedand check the commit log for every plugin and see if there's actually been a new release as opposed to new commits, but would need to be done "manually" and wouldn't be done all the time as you need to go through every plugin with new commits and skim its commits
Additional context
No response