Change timestamp at the end of release files for a hash

[iranreyes]

One of the goals about splitting the bundle in two files, one with the actual code and another with the vendors it is the catching of the vendor bundle. How everybody knows the vendor bundle is less probable to change in production than the actual code bundle.

However in our current implementation we are suffixing every bundle with a timestamp and the vendor bundle will have a different name in every release. This issue will be fixed quickly using a hash function instead of a timestamp.

The bad part is the time cost for bundling. So, we can let it open for timestamp or hash. In my case I prefer 1 minute more of bundling and better caching of resource.

:-)

[jeremenichelli]

We should definitely move from changing the filename to something like ?v=SOME_HASH_HERE and detect which files were modified to improve caching, and prepare the ground to introduce service workers in the future too.

[njam3]

This is intended as a debugging measure only (ensure someone viewing it does not have a cached version) and has been disabled by default (recently). If you want to turn off timestamps on a previous version of a generated project, simple set timestamp: false in config.json. Due to the use case for the timestamp option, at this point I do not feel like it is worth the time to patch in a hashing function as well.