(Trying to find the path to progress here, not advocate for any certain outcome btw)
> This testing matrix has to be done, and the earlier it is done (and done by > the author) the better. I like the author owning it. I'm also concerned the author might not have context and expertise in a domain that breaks and needs modification (i.e. core C* dev changes utils, that change breaks something in analytics, ???). It does keep the responsibility for making sure breakages are resolved closer to the changer which is also positive - the earlier the better indeed. How do we run CI for everything? That's a huge lift. If we *do* manage to get that setup, won't that just discourage people from moving code into utils or modifying existing code since then you're subject to the flakiness of all the projects CI combined instead of just one project's? On Wed, Aug 19, 2026, at 3:23 PM, Mick wrote: > > > > Changes to libraries that fix one consumer can > > break another: we will need to be able to build and run tests for all > > dependent projects when we make changes > > > I agree with Benedict here. > This testing matrix has to be done, and the earlier it is done (and done by > the author) the better. > If we're honest about that, then the API labelling and versioning isn't > needed. > > Pushing the complication onto the consumer in following such api labelling > and versions, and then finding out late things don't work for them and > another change in the utils repo is needed, doesn't sound fun. Let's just > keep it simple and encourage everyone to say close, via authors taking full > responsibility for a change they make at such low-level and shared code. > >
