BuildStream-Migration-Bot opened a new issue #1385: URL: https://github.com/apache/buildstream/issues/1385
[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/1385) In GitLab by [[Gitlab user @tristanvb]](https://gitlab.com/tristanvb) on Aug 16, 2020, 09:07 This is a flagship issue for the [2.0 milestone](https://gitlab.com/BuildStream/buildstream/-/milestones/3), 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](https://mail.gnome.org/archives/buildstream-list/2020-April/msg00013.html). 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. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
