-
Notifications
You must be signed in to change notification settings - Fork 18
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
--force-version could be more flexible #36
Comments
Does it help to run |
what if we add a new option called |
Yeah that's what I currently do, but it adds that extra step 😬 #lazy The ideal behaviour I'd expect is that if I only provide the major version, it picks the highest available version within that major. For example:
So in my ideal world, we'd keep backwards compatibility and only have to memorize one argument. |
I like this option! Thanks for the explanation and the brainstorming! |
For completeness, I should mention my ultimate dream, which is in #9, i.e. |
The
--force-version
option only accepts a fully-qualified version, for example:--force-version 3.7.0
. As a user, I often don't know what specific minor and patch versions I'm in, but I really care about what major version to use. It would be helpful if this flag were more flexible and would choose the best-fitting version based on a given major version.It's also worth mentioning that it's not common to have multiple minor / patch versions of the same library available to the command line at the same time, so users will rarely want to choose a specific minor version.
The text was updated successfully, but these errors were encountered: