The obvious problem around #3, as others have stated, is when we have an unhappy logical conflict in behavior that breaks one client while it fixes another. That will probably require collaboration across projects no matter what we do or who validates the change, but finding it a little later is something I'd trade away to encourage sharing in the first place.
On Wed, Aug 19, 2026 at 6:39 PM Caleb Rackliffe <[email protected]> wrote: > > 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? > > My honest assessment of my own behavior and motivations leads me to > say...yes. > > It seems reasonable to arrive in a situation where: > > 1.) We have annotations to *communicate intent* and allow for > experimentation in the shared space. > 2.) We require shared library changes to simply *not break the builds* of > ecosystem projects. (It seems like the argument here is over whether we'll > have a versioning apparatus that *does* allow this?) > 3.) Particular ecosystem projects manage the safety of their own > consumption of the shared library. > > On Wed, Aug 19, 2026 at 4:03 PM Josh McKenzie <[email protected]> > wrote: > >> (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. >> >> >> >>
