-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: See outdated versions with version
#1729
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
No stale |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
No stale |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
No stale |
Did you check the 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). Withcheck_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 useversion
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 thatcheck_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 setcheck_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 bumpversion
, check for breaking changes, update your config if needed and update.Describe alternatives you've considered
check_pinned
and 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 commitsAdditional context
No response
The text was updated successfully, but these errors were encountered: