[Feature Request] fvm install 2: infer the latest minor/patch version when supplying the major version

[th0rgall]

Problem description

I just installed fvm, intending to use it to switch quickly between the latest flutter 2 release and the latest flutter 3 release.

After installation, I intuitively ran fvm install 2 to download the latest Flutter 2 SDK with fvm and get started with my configuration.

fvm printed:

Flutter "2" is not installed.

Installing version: 2...
Cloning into '/Users/thor/fvm/versions/2'...
fatal: Remote branch 2 not found in upstream origin

Could not install 2

Please run command with  --verbose if you want more information

I did not expect this error. I would expect fvm install 2 to install the latest stable Flutter 2 release at the time of running the command. It would expect it to be equivalent to the working command fvm install 2.10.5@stable.

Describe the solution you'd like

I had an expectation mismatch because I expected installation behavior similar to the node version manager. Since many folks in the flutter space come from web development, there might be more people who are used to nvm.

To compare, if you run nvm install 14, it installs v14.19.3, which is the latest stable 14.x.x release. The command inferred the latest available patch version of the latest minor version in semantic versioning.

You can also specify the only the major and minor version, and leave the patch version open, for example, nvm install 14.10 would install v14.10.1, where the .1 is the last available patch version in that minor version range.

I would like fvm to also implement this behavior.

Describe alternatives you've considered

The alternative is what I did to fix my problem:

1. Googled for the Flutter SDK GitHub project (because fvm seems to directly use git to download versions)
2. Looked at the tags there: https://github.com/flutter/flutter/tags
3. Figured out 2.10.5 is the latest stable 2.x.x flutter release at the time of writing.
4. Ran fvm install 2.10.5. All good!

Additional context

I read the principles.

I think this change would make the fvm API simpler to use. It reduces my mental load by not requiring me to know or look up what the last Flutter 2 release is.

At the same time, I recognize that this extra version inference layer would make fvm use git less directly, which might distance it a bit from flutter's usual installation methods. I think it's worth it.

[leoafarias]

@th0rgall I don't know how I feel about this... I definitely see some benefit of doing that.. but in the example of Flutter 2, if I want version 2, would be 2.0.0, not the latest

Maybe a better implementation that could also solve the problem of keep it up to date ongoing is constraints.

For example on the fvm config you could do ^2.0.0, and it would always use the latest 2.0.0 version, and you could use things like >=2.10.0 <3.0.0.

[th0rgall]

but in the example of Flutter 2, if I want version 2, would be 2.0.0, not the latest

I agree that this is subjective & ambiguous.

It could work like this, if the version implied is not clear:

thor@mbp ~ % fvm install 2
Which version do you want to install?
1) 2.0.0
2) 2.10.5 (latest stable 2.x.x release)

Where it would allow you to select the version interactively. Provides a good UX imo, but probably adds some implementation complexity.

Alternatively, I think this current message is also good, and could be expanded upon:

thor@ThorsWokstation ~ % fvm install    

Please provide a channel or a version, or run this command in a Flutter project that has FVM configured.

That error message is better than the git error message that I got, I think.

You could suggest example commands depending on the input, which would've equally helped me with my problem:

thor@ThorsWokstation ~ % fvm install 2

Please provide a channel or an exact version, or run this command in a Flutter project that has FVM configured.

Did you mean to install the latest Fluter 2.x.x release? Then run:
fvm install 2.10.5

thor@ThorsWokstation ~ % fvm install    

Please provide a channel or an exact version, or run this command in a Flutter project that has FVM configured.

Example usage: fvm install stable

Maybe a better implementation that could also solve the problem of keep it up to date ongoing is constraints.

For example on the fvm config you could do ^2.0.0, and it would always use the latest 2.0.0 version, and you could use things like >=2.10.0 <3.0.0.

Do you mean that if you run fvm install in that project, it would resolve to the latest version allowed by the constraints, and install that one? I actually see benefits in not supporting ranges, and locking down an exact version for dev env parity across team members.

I don't think .nvmrc allows version ranges, or it does not seem to be intended at least.

The problem I posted is related to transitioning to fvm for the first time in a project. Then the flow is something like this now:

brew install fvm
fvm install 2.10.5 # <= this is where I could have used some guidance, see above
fvm use 2.10.5

I would have also found it useful that after running fvm install 2.10.5, it would tell me:

Run "fvm use 2.10.5" to use this version in your current working directory.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[martin-braun]

Just for the record, nvm acts in the same way. nvm install 16 will install the latest minor version of the major version 16. Please consider to implement this feature, it would be very handy for me as well.

[MobiliteDev]

Any news on this subject ? It would be great to have the possibility of automatically take the latest minor version somehow

[leoafarias]

@MobiliteDev no news on this yet, I might take a look before 1.0 which will be soon