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

--force-version could be more flexible #36

Closed
chapulina opened this issue Jan 26, 2021 · 5 comments · Fixed by #44
Closed

--force-version could be more flexible #36

chapulina opened this issue Jan 26, 2021 · 5 comments · Fixed by #44
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@chapulina
Copy link
Contributor

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.

@caguero
Copy link
Contributor

caguero commented Apr 5, 2021

Does it help to run --versions? I'm a bit hesitant to change the behavior of --force-version but we could add another option --force-major-version if needed.

@scpeters
Copy link
Member

scpeters commented Apr 5, 2021

what if we add a new option called --force-exact-version that uses the current behavior, and then change --force-version to accept the most recent Patch if only Major.Minor are specified or the most recent minor if only the Major version is specified. I think it's ok to make a behavior change that relaxes the strictness, though it would be a breaking change to go in the reverse direction. That's my opinion

@chapulina
Copy link
Contributor Author

Does it help to run --versions?

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:

$ ign topic --versions
9.1.0
9.0.0
8.2.0
10.0.0
# All these pick 9.1.0
ign topic --force-version 9
ign topic --force-version 9.1
ign topic --force-version 9.1.0

# These pick 9.0.0
ign topic --force-version 9.0
ign topic --force-version 9.0.0

So in my ideal world, we'd keep backwards compatibility and only have to memorize one argument.

@caguero
Copy link
Contributor

caguero commented Apr 5, 2021

Does it help to run --versions?

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:

$ ign topic --versions
9.1.0
9.0.0
8.2.0
10.0.0
# All these pick 9.1.0
ign topic --force-version 9
ign topic --force-version 9.1
ign topic --force-version 9.1.0

# These pick 9.0.0
ign topic --force-version 9.0
ign topic --force-version 9.0.0

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!

@chapulina
Copy link
Contributor Author

For completeness, I should mention my ultimate dream, which is in #9, i.e. ign topic --citadel 😅

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

Successfully merging a pull request may close this issue.

3 participants