How to manage common library dependencies to prevent cross-application breakage? [closed]

Note: The question was heavily rewritten after the comments it received. I work on a team that develops embedded software for various in-house devices. Each device hosts multiple "bare metal" applications—all compiled into self-contained binaries—and we also maintain a set of common static libraries (e.g., for networking, cryptography, etc.) used by the applications. All the code lives inside a single per-device repository where every commit goes into a main branch. This setup has led to a major problem: Team members that are working on one application are breaking others application and work by committing changes to the common libraries. Developer of "App B that uses Lib A" has no way to choose a fixed version of the "Lib A" for his release. If developer of "App A that uses Lib A" needs to make a required breaking change it has to wait for the other developers to be ready before doing it's commit. The codebase currently does not support automated testing. Making the code testable requires heavy refactoring that in the current situation we can't easily do because of the above It's something we are aiming to do after resolving or making this issue less problematic. What strategy can we adopt to resolve the above problem?

Apr 14, 2025 - 21:25

Note: The question was heavily rewritten after the comments it received.

I work on a team that develops embedded software for various in-house devices. Each device hosts multiple "bare metal" applications—all compiled into self-contained binaries—and we also maintain a set of common static libraries (e.g., for networking, cryptography, etc.) used by the applications. All the code lives inside a single per-device repository where every commit goes into a main branch.

This setup has led to a major problem: Team members that are working on one application are breaking others application and work by committing changes to the common libraries.
Developer of "App B that uses Lib A" has no way to choose a fixed version of the "Lib A" for his release.
If developer of "App A that uses Lib A" needs to make a required breaking change it has to wait for the other developers to be ready before doing it's commit.

The codebase currently does not support automated testing. Making the code testable requires heavy refactoring that in the current situation we can't easily do because of the above It's something we are aiming to do after resolving or making this issue less problematic.

What strategy can we adopt to resolve the above problem?