When NetLogo Web is published, most assets get a unique name/hash generated in the release process. The unique name means after the release the updated versions of these files are seen as new by browsers and downloaded fresh. Some files have static names, notably netlogo-engine.js, tortoise-compiler.js, the various landing pages (launch, web, etc), and the models library .nlogo files. This means when a release goes out, web browsers can continue showing cached versions of the page.
The engine and compiler should probably have their actual release versions include in the file name.
The landing pages should have as much code as possible moved into JavaScript files (which are versioned). I think this is already mostly complete after the work to move to ES6 modules.
The models library is a tougher one, as it feels like we do want a canonical URL for each model, as opposed to listing it by NetLogo desktop release version or similar. Model changes are even less frequent than NLW code changes, so this might not be worth worrying about.
This is a minor issue in practice. Most browsers seem to pick up on the changes in a reasonable amount of time. It's only particularly aggravating when a high priority bug fix is released and the users affected all need to clear cache for the site or run in incognito mode to get the latest code. There may be some AWS caching settings that could help here, too. I looked into it a bit a long time ago, but didn't manage to get much tested out.
When NetLogo Web is published, most assets get a unique name/hash generated in the release process. The unique name means after the release the updated versions of these files are seen as new by browsers and downloaded fresh. Some files have static names, notably
netlogo-engine.js,tortoise-compiler.js, the various landing pages (launch,web, etc), and the models library.nlogofiles. This means when a release goes out, web browsers can continue showing cached versions of the page.This is a minor issue in practice. Most browsers seem to pick up on the changes in a reasonable amount of time. It's only particularly aggravating when a high priority bug fix is released and the users affected all need to clear cache for the site or run in incognito mode to get the latest code. There may be some AWS caching settings that could help here, too. I looked into it a bit a long time ago, but didn't manage to get much tested out.