Hi Aleix, Le jeu. 9 oct. 2025 à 17:03, Aleix Pol <[email protected]> a écrit : > As you'll see there, I was pointed out that such fixes would incur in a > policy violation. Now, while we don't want to break anything, it sounds > like we also should be able to come up with a mechanism. I am not as > well-versed in the buildstreams than others here, so I'll appreciate any > ideas.
Thanks for bringing this up. We should indeed have a documented way to "fix" our frozen plugins. > It occurs to me, for example, that we can have some elements with a > -next postfix and these do not abide by the cache key stability rule. > Once bst 3 is released, the -next elements can be folded back into their > stable ones and we'll also know we have well-tested elements to release > instead of doing them all at once. I don't think this works. We could certainly do it, but these plugins would be unusable the same way other plugins in the collection can be used. So they need to be somehow marked as unstable. Instead, we could have these plugins in the community plugins collection [1] where no such stability rule exists. At the point of moving to bst 3 (which is probably still very far away), we could take the opportunity to upgrade the official plugins to the latest. We already have an instance of a cargo2 plugin in buildstream-plugins-community (vs cargo in buildstream-plugins). Though the reason for the split was different, I think it makes sense to do something similar in this case. What do the others think? Abderrahim [1] https://gitlab.com/BuildStream/buildstream-plugins-community
