Asset versioning and deployments

Another question asked on Symfony Slack (@jderusse asked it):

regarding the new Encore component and asset versioning (http://symfony.com/doc/current/frontend/encore/versioning.html) what is the simplest strategy to avoid 404 during a deployment (1) user gets http page pointing to asset version A, 2) a new version B of the app is deployed, 3) user ask for asset A which no longer exists) Why not using a “queryString” strategy like describe in http://symfony.com/doc/current/frontend/custom_version_strategy.html

[weaverryan]

The only fool-proof approach is a “never delete old assets” approach… or at least a "only delete old assets… after some time has passed). This is pretty standard if you’re using a CDN - e.g. CloudFront I believe keeps your old assets for 24 hours.

In summary: A) Best Solution: Don’t delete old assets, either by removing cleanupOutputBeforeBuild() or using a CDN that stores your old asset URLs for a little while B) Great Solution: Use a decent deploy (e.g. the Capistrano philosophy) where you completely finish deploying and building your code before new traffic hits things. You shouldn’t see any 404’s, except in edge-cases (that Stof mentioned). C) Not Great Solution If you have a deploy that continually serves traffic and deletes the old assets (e.g. an Rsync solution), your assets will 404 for a little while during deploy. Either make your deploy process better or use a different versioning method (like what Stuf suggested)

There’s nothing to do in Encore, but we could add a small note about this in the versioning section.

[weaverryan]

I’m going to close this (see the open docs issue) - we’ll document this as well as possible