Curious how people handle this function versioning and tag and releases in team environments.
Let’s say on a branch I create Function A and release 0.0.1-rc-somename.
On the same branch I create Function B, which internally calls Function A. I release Function B as 0.0.2-rc-somename2 and left Function A untouched at 0.0.1.
Neither is on master yet (life happens).
Then a bug shows up in Function B. I create another branch on top of the existing one. The fix requires changing logic in Function A, so I release a new version of A and update Function B to consume it. Function B is now released as 0.0.3-rc-somename3 but A is not updated (Under Rule 0 of coding: If it works don’t touch it).
Everything is working, nobody is complaining 
Later, more work happens on that new branch and Function A gets another release: 0.0.4-rc-somename4.
Meanwhile, a PR gets merged to main that is still aligned with the original 0.0.1 and 0.0.2 versions of Functions A and B.
Now imagine I’m a completely different developer joining the project.
I open the code and see:
-
Main has Function A with logic Z (
0.0.1) -
Function B (
0.0.3) was built against a newer version of Function A with logic Y -
The latest tagged Function A (
0.0.4) has logic X
When I start a new branch, I naturally start from main. So I don’t even have the changes that exist in those tagged versions.
Even if I’m diligent enough to go hunting through tags, my likely reaction is to copy-paste code from the latest tag. But then how do I know whether B should be using logic X from A 0.0.4, logic Y from the version it was originally tested against, or logic Z from main?
At that point it feels like development is happening in parallel timelines and I’m one bad assumption away from losing months of work 
Do people run into this often?
How do teams keep track of what is actually running where when RC versions, branches, and shared dependencies start evolving independently?