Skip to content
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

Open
1 task done
nihaals opened this issue Aug 29, 2024 · 6 comments
Open
1 task done

feature: See outdated versions with version #1729

nihaals opened this issue Aug 29, 2024 · 6 comments
Labels
enhancement New feature or request stale

Comments

@nihaals
Copy link

nihaals commented Aug 29, 2024

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_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 commits

Additional context

No response

@nihaals nihaals added the enhancement New feature or request label Aug 29, 2024
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Sep 28, 2024
@nihaals
Copy link
Author

nihaals commented Oct 1, 2024

No stale

@github-actions github-actions bot removed the stale label Oct 2, 2024
Copy link
Contributor

github-actions bot commented Nov 1, 2024

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.

@github-actions github-actions bot added the stale label Nov 1, 2024
@nihaals
Copy link
Author

nihaals commented Nov 1, 2024

No stale

@github-actions github-actions bot removed the stale label Nov 2, 2024
Copy link
Contributor

github-actions bot commented Dec 2, 2024

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.

@github-actions github-actions bot added the stale label Dec 2, 2024
@nihaals
Copy link
Author

nihaals commented Dec 3, 2024

No stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request stale
Projects
None yet
Development

No branches or pull requests

1 participant