Date

Sat Jun 10 2023

Author

georges-gomes

Longer life for cache

Up until now (jampack v0.12.2), the cache was versionned with the version of jampack. This was a guarantee that the cache consumed by jampack was always up-to-date with the code. Avoiding bugs to stay in the cache.

This means that everytime, the user upgraded to a new jampack version, everything would need to processed and cached again. And when you have thousands of images, it’s not a small job.

It was OK at the begining because so much changes were going on in with the image processing that pretty much every new version required a fresh new cache.

But now, new versions are just adding new features or fixing bugs that are unrelated to images. Reprocessing the cache for these updates is a waste of time.

Also, with the recent addition of new cache category for external images, the cache is splitted in different types of data and they don’t need to be affected together.

Cache structure before

/.jampack/cache/0.12.2/img/...
/.jampack/cache/0.12.2/img-ext/...

Cache structure now (0.13.0+)

/.jampack/cache/img/v1/...
/.jampack/cache/img-ext/v1/...

v1 is the version number of the cache and it can now be adjusted individually for img (local image processing cache) and img-ext (external images).

Migration

jampack will automatically delete all cache structure and create the new one. There is no need to delete the old cache manually.

Downside

The downside is that the version number of the caches must be manually ajusted before release if bug fixes or features affecting the cache are not backward compatible with older caches.

It requires more discipline. But it’s easy to fix in a patch.

Release

• 0.13.0