This is definitely not documented, but the plugin works by obtaining the information from the version.json stored where the app is running from. So it depends on whatever is in that version.json file.

When looking at the code then cache is deliberately being avoided
https://github.com/fluttercommunity/plus_plugins/blob/2119168267e436e5900ea09cf68dd110e51b01e0/packages/package_info_plus/package_info_plus/lib/src/package_info_plus_web.dart#L45C1-L48C54

Yes, implemented here some years ago: 25e72e7

The original ticket has some information about this: #225

I am not a web expert, so I cannot chip in if this is correct or not.

The source of the problem I think is the nature of the web implementation, that is dependent of an external resource that needs to be loaded with a fetch request (GET version.json) and as all web resources, it has its own cache.

You can remove the buster cache, but then you will depend of the browser cache invalidation. Your main.dart.js and your version.json can be invalidated in different moments, so you will be in the same situation.

And this only thinking in the browser cache invalidation, but it could be other cache layers, like for example an AWS CloudFront cache invalidation layer, or others.

It is a complicated situation, to be honest.

We could add a new parameter to opt out the cache buster. Maybe that could mitigate the issue, but in my view, it will be there yet, just happening sometimes, instead always.

Or, we could implement a solution no dependent of the version.json file. For example, in the web build process of the app, the package could inject the same information that we can find in the version.json file in a dart file. In that way, you can know exactly which version of the app you are seeing in your browser, because the information it is in the same main.dart.js of your app.

Of course, this is just a theoretical solution and I don't know if it could be implemented even.

I'll suggest you could collect the version mentioned in the pubespec.yaml file and refer it as "cachedVersions", so when you reference that you are not relying on the /version.json implementation.

You may need to implement it with a builder like dart run build_runner build --delete-conflicting-outputs to generate the .dart files, then theese will (may?) be a part of "static" pages in the browser, and you can then compare that version to the version provided with the /versjon.json from the recently published one.

This may solve the problem mentioned above also, on how to inform the user that there is an updated version of the (web)app, and you need to refresh it (done programmatically or by Ctrl+F5)

Maybe here are some hints on collecting the pubspec.yaml version info on build.

https://stackoverflow.com/questions/23613279/access-to-pubspec-yaml-attributes-version-from-dart-app

https://stackoverflow.com/a/75064421/4475206

I made a suggestion to the flutter team, maybe they hear us...
flutter/flutter#149725

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days

Keep open.

Discussed in flutter/flutter#149031

Personally I think that appending the cachebuster query string is a very good intention, but unfortunately results in unwanted behavior. The underlying issue is definitely in the framework, but I think most devs would prefer the reported version to be the actual version of the other loaded assets than the most recent deployed version.

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days