Cache keys must be stable indefinitely
This is a flagship issue for the 2.0 milestone, as some related issues have been added there but nothing which guarantees cache key stability for 2.0
explicitly.
It was decided that BuildStream 2.0 would feature stable cache keys.
In order to release 2.0
, we need to have a strategy in place for how the format evolves while guaranteeing cache key stability for the same inputs moving forward.
This guarantee must be maintained by core plugins maintained by the BuildStream community, but is not a requirement for third party projects (nor can it be practically guaranteed by BuildStream).
-
get_unique_key()
implementations must be backwards compatible when including new format related configurations - Extensions to the artifact metadata format itself must be backwards compatible
- This is to say that BuildStream must support working with older artifacts moving forward if the internal artifact format changes
- This can also mean that some newly added BuildStream features require newer artifact formats, and cannot work without explicitly opting into a new format which changes a cache key. In these corner cases, the user must retain the choice to keep using the old artifacts and not use the new feature.