You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I believe FVM is a perfect solution to have multiple versions of Flutter in the project.
I.e. the git branch(es) for the ongoing development use the most recent Flutter version. At the same time we have maintenance branches, in which we provide bug-fixes for the already released versions.
The maintenance branches should keep their dependencies 'frozen' and always use Flutter version with which they were released. At least until we decide to upgrade Flutter to the latest bugfixing version, or so.
The git-managed .fvmrc and .vscode/settings.json are already getting into this direction. Whenever I checkout a maintenance branch, they are updated accordingly and use the version I need.
Unfortunately, the gitignored .fvm folder is not updated and causes inconsistency. And error message The SDK configured in dart.flutterSdkPath is not a valid SDK folder. in VS Code.
Then it gets somewhat tricky to bring it to consistency with fvm use.
Describe the solution you'd like
I would like the Flutter version to always match the one in .fvmrc. And auto-switch whenever it is updated.
For this, I beliieve the following is needed:
.fvm folder should not contain anything except of the versions subfolder
a Flutter version, one linked with fvm use command, should never be unlinked. In particular, it should not be unlinked when fvm-using another version. Then the version/path referred-to from .vscode/settings.json would always work.
I do not know what .fvm/flutter_sdk link is for. If this is really necessary, and could not be removed, perhaps it could be linked to the version link in versions subfolder. This would make it relative. Then it could be git-managed and updated accordingly on checkout.
The other files (release, version, fvm_config.json) seem excessive to me. I could add them to git though, if they cannot be removed.
So two critical changes to make the behavior happen are:
keep symlinks to all used versions, not only ot the current one
remove or make relative the symlink .fvm/flutter_sdk
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I believe FVM is a perfect solution to have multiple versions of Flutter in the project.
I.e. the git branch(es) for the ongoing development use the most recent Flutter version. At the same time we have maintenance branches, in which we provide bug-fixes for the already released versions.
The maintenance branches should keep their dependencies 'frozen' and always use Flutter version with which they were released. At least until we decide to upgrade Flutter to the latest bugfixing version, or so.
The git-managed .fvmrc and .vscode/settings.json are already getting into this direction. Whenever I checkout a maintenance branch, they are updated accordingly and use the version I need.
Unfortunately, the gitignored .fvm folder is not updated and causes inconsistency. And error message The SDK configured in dart.flutterSdkPath is not a valid SDK folder. in VS Code.
Then it gets somewhat tricky to bring it to consistency with
fvm use
.Describe the solution you'd like
I would like the Flutter version to always match the one in .fvmrc. And auto-switch whenever it is updated.
For this, I beliieve the following is needed:
fvm use
command, should never be unlinked. In particular, it should not be unlinked when fvm-using another version. Then the version/path referred-to from .vscode/settings.json would always work.I do not know what .fvm/flutter_sdk link is for. If this is really necessary, and could not be removed, perhaps it could be linked to the version link in versions subfolder. This would make it relative. Then it could be git-managed and updated accordingly on checkout.
The other files (release, version, fvm_config.json) seem excessive to me. I could add them to git though, if they cannot be removed.
So two critical changes to make the behavior happen are:
The text was updated successfully, but these errors were encountered: