version.json essentially is a build artifact, that has no place to be checked in with master. In essence, it is a moving target, and each and every commit must touch that file.
For releases, this is not a big deal: just generate it using make release. However, the code currently has a hard dependency on the contents of this file to generate cache invalidation additions.
In a development scenario, this logic is fundamentally flawed anyways; I want reloads on every request that the actual file has changed.
So my proposed solution would be:
- nuke
version.json from the repository, but generate an manifest file on every build.
- The version of the manifest is determined by
git describe --tags
- Stop using the version as a cache invalidation method in the url. Instead use sha1(sha1(grocy.js) + sha1(grocy.css)) as a content hash. This has the slight downside of reloading the cache if either grocy.js or grocy.css change, but is stable in scenarios where not-grocy is installed from git and upgraded between releases.
- Put all these things into a php file
manifest.php and include that. There is absolutely no reason to use json here, this file isn't consumed by anyone.
version.jsonessentially is a build artifact, that has no place to be checked in with master. In essence, it is a moving target, and each and every commit must touch that file.For releases, this is not a big deal: just generate it using
make release. However, the code currently has a hard dependency on the contents of this file to generate cache invalidation additions.In a development scenario, this logic is fundamentally flawed anyways; I want reloads on every request that the actual file has changed.
So my proposed solution would be:
version.jsonfrom the repository, but generate an manifest file on every build.git describe --tagsmanifest.phpand include that. There is absolutely no reason to use json here, this file isn't consumed by anyone.