> One solution is to version your JavaScript files (first release in a /v1/ directory, second in a /v2/ etc.). Then the rollout simply consists of changing the resource links in your root pages to reference the new (or old) versions.
I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.
If one.js changes but two.js doesn't, then two.js should come from the cache. Only one.js should be fetched from network. Sticking all assets in an /assets/v2 folder invalidates everything.
If one.js and two.js are really separate components, they should each get a version.
If they're closely coupled, they should be compiled together into one unit, to take advantage of deduplication, inlining, dead code elimination, fewer requests, better compression, etc etc.
Versioning assets separately by sticking them in new subfolders is just re-inventing ETags in a bad way. Just use ETags.
The point of the folder versioning scheme the article proposes is to make rollbacks easier. You can easily rollback a /assets/v2 folder to /assets/v1 by updating your server template, but if you have a dozen separate version folders (with different latest version numbers) for each resource then it's no longer easy to roll those all back.
That's fair. Most apps I have worked on have very few bundles of JavaScript that we either served inline or in one request, but I can see how this helps in the case of many requests.
I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.