Declare clear upgrade policy when installing the SDK via snap on Linux

[MrCsabaToth]

Page URL

https://docs.flutter.dev/get-started/install/linux

Page source

https://github.com/flutter/website/blob/main/src/get-started/install/_get-sdk-linux.md

Describe the problem

The Flutter SDK upgrading policy may not be clear for developers.

If the snap package keeps getting refreshed (now that flutter/flutter#93497 is fixed) with beta or stable builds then someone might actually rely purely on snap refresh flutter and don't flutter upgrade. But in that case that person needs to be aware of the situation and stick to snap and stay away from flutter upgrade. However, IDEs like Android Studio would probably (I haven't checked) advise flutter upgrade still when a new version is detected and not snap. Once Flutter SDK is upgraded through the flutter CLI then the developer should stay with the Flutter CLI and don't upgrade it via snap because in any case there would be some version difference it could be a downgrade.

The bottom line is that although this page is mainly about installation, to avoid possible future confusion there should be a short {{site.alert.note}} (or similar) section which would warn the user: either upgrade the Flutter SDK after installation and then stick with the CLI, or stick to the snap channel supplied installation but do not mix the two in case they are not in sync.

If a developer uses snap to maintain other SDKs and technology stacks a generic snap refresh (bring all snap packages to latest) might trump over the fresh Flutter CLI upgrade. I'm not using snap but I can also imagine since snap becomes Ubuntu's app store that the user would get notifications on the system about the new snap package version shortly after the new Flutter build is pushed there.

Expected fix

The statement has to be brief so it wouldn't derail the purpose of an installation but also be visible. The snap method already has a {{site.alert.note}} block about the SDK path. Maybe right bellow that there could be another {{site.alert.note}} block with something along the line of "We advise to keep the Flutter SDK fresh after installation via the CLI methods. We don't recommend mixing the upgrades based on Flutter CLI vs snap. Time-to-time there could be version differences.". Maybe there's a better place for the policy in a little more detail somewhere else in the documentation in which case there could be a link here to that place.

Additional context

Since #4341 snap installation is the primary recommended method on Linux. It's undoubtedly simple with only one command and snap is part of some distributions by default. I've seen in the wild though that developers new to Flutter but accustomed with snap may expect to keep the Flutter SDK updated through snap (via snap refresh flutter). The snap package wasn't updated since August, and developers who assumed snap packages will be kept in sync with Flutter releases. This was a bug in the Flutter SDK build pipeline which seems to be fixed now, however that pointed out to me that the upgrade policy need to be advised briefly.

Should we look at snap as an installation vehicle only and direct the user immediately to Flutter CLI? The installation guide advises a Flutter doctor which should warn if there's a new version available even in the beginning. If someone follows the tutorial and then listens to Flutter doctor's advise that would result in a flutter upgrade. And Flutter CLI is the standard on all other platforms and the secondary Linux method as well. But in this case the installation documentation should clearly define that snap is used for an easy and simple one command installation and nothing more.

If someone wants to stick with snap based upgrades then we need to warn that versions might got out of sync and do not mix the Flutter CLU upgrade vs the snap based upgrade.

I'm a Linux user but I installed Flutter manually, so I was not aware that snap installation may pose other problems: #6460. I'm not sure how common or serious are those errors (could they be also due to the snap package versions lagging behind in the past before as well?), but even if snap might become a secondary method one day this explicit upgrade policy is still important in my opinion. Maybe it's a question where it should be raised.

[MrCsabaToth]

I don't have snap, but I can imagine that now as the snap builds will be released regularly again a developer might get warnings about new versions both from snap (advising snap refresh) and both from the IDE / Flutter doctor (advising Flutter CLI based refresh), which can be confusing.

[MrCsabaToth]

Actually, I just talked with a developer with a Mac OSX primary developer machine and the same question arises with brew. Today (Dec. 30 2021) SDK 2.8.1 is already out as the latest stable. Snap has the Nov 15 2.8.0 still (if I'm correct), and brew theoretically has the 2.8.1 but my friend's brew haven't received it yet. So if he upgrades the Flutter SDK with CLI, what will happen in the future? Should he stick with CLI from then on? Will brew (or snap) interfere once it realizes there's a new build? (probably, and at that point the CLI may also moved on to an even newer build)

[MrCsabaToth]

Here is a correspondence from the Canonical repo issue about the snap being outdated: canonical/flutter-snap#64.
So snap is just an installation vehicle, users should never update via snap after install, should stick to the Flutter CLI. Seemingly some developers skimmed over the part that right after install flutter doctor should be executed.
There's already a Note section about the SDK path of the snap install method. I'd propose to add another Note there which would warn the user to stick to the Flutter CLI for further updates and refrain from snap updates.