Community migration path to v3

[jibbers42]

If I'm reading the v3 changelog correctly...

Config file is now .fvmrc instead of .fvm/fvm_config.json, and .fvm can be added to .gitignore, FVM will migrate it automatically.

It seems that a one time migration from .fvm/fvm_config.json to .fvmrc will occur, but after further version updates I'm guessing the version will be out of sync for users on fvm v3 vs fvm v2, depending on which made the latest flutter version change. (The changelog note also implies that .fvm may be added to .gitignore during the migration, but I think that may just be a wording issue)

I assume once someone on the project updates to v3 then they will need to deal with an auto generated .fvmrc. They can either commit it, ignore it, or .gitignore it. At some point when .fvmrc makes it's way into the repo, users will need to keep .fvm/fvm_config.json and .fvmrc manually in sync until the project decides that only fvm v3 use is supported. Until .fvm/fvm_config.json is removed from .git, requiring all users to upgrade to v3, then if the files become out of sync some people will be on the wrong flutter version.

I'm curious if this is expected or if I misunderstand?

Would the following be reasonable advice?...

• Add .fvmrc to .gitignore until the project is ready to require fvm v3. Any users already on fvm v3 will get .fvmrc auto generated.
• When the project moves to fvm v3 add .fvmrc to git then git remove and .gitignore .fvm/fvm_config.json.

After typing the above points, I realize the v3 user case when when .fvm/fvm_config.json is updated by a v2 user. I'm guessing fvm v3 won't override an existing .fvmrc with an updated .fvm/fvm_config.json - so the first point may not be good advice.

Am I missing the obvious path to fvm v3 - or is the risk of some users on the wrong version just considered not a very big deal while the install base transitions to v3?

[leoafarias]

@jibbers42 let me know if this solution works.
#631

[jibbers42]

Thanks for the changes! It looks like you're now maintaining the legacy config on save. I made a comment where I think the new config might need to be loaded inside the if block on migration.

The only issue I see is this always prioritizes the existence of a v3 config, so if a v2 user updates the version then that will apply to all v2 users, but no v3 users. If both configs exist and the common settings differ, then the v2 must be newer (unless v3 was manually edited), right? Perhaps in this case v3 should be updated on load?

[jibbers42]

I understand if you want to allow manual v3 editing. In that case you could just error out with an explanation - or even prompt the user to choose the correct values if you wanted to go that far with it.