How do you communicate the mistake to the developer?

Is your definition of a mistake a change that makes your code no longer work, are are these changes being made for a reason and it's your code that needs to adjust?

@Blrfl, these changes are usually made (for a reason) to a shared piece of code, and everyone changing it knows that they should be very careful changing it, and take for account all possible situations. The mistake is that it didn't account for mine.

@L.Dutch, thanks, I added what you asked for

@JeffO - TFS can be set up to auto reject code checkins with broken tests... And its pretty easy to do

There needs to be a team consensus (or a management decision) to have an automated testing infrastructure, and someone needs to make up the rules, set up the system, maintain it. It's a good thing to have, but it's never easy to introduce it to a team, especially not if the team dynamics are complex. Remember developers are people, and people tend to disagree.

Blame the code, not the developer.

@IDrinkandIKnowThings - That's true, but someone in authority would have to make that decision to enable that feature. My guess is in the OP's case, they're not interested in having that much structure.

@JeffO which is what I was suggesting in the comment in the first place. And why its not an answer.

Why does your code break in the first place?

Well, if you change something without checking and you break other things, who else should be blamed?

"The code I'm working on is assuming that X is always in the range 1 to 5, but it seems that's no longer true, it can now be 6. Was that change intended? How should I handle the new value?".

I don't think we have enough information to make judgement on fault here. The modules should be interacting based upon an agreed-to standard. Did the change by the other developer break that standard? It's their "fault." Did the OP's code not correctly handle a change that was in bounds to that standard? It's the OP's "fault." On the other hand, is there no standard interface for the modules? That's everyone's fault, and it's no wonder this situation is happening. It's hard to specifically answer the question without knowing which of these situations is actually playing out.

On the technical side: CI builds with tests, Code reviews, no pushing directly to trunk (merge updates to feature branch, build, test, review then apply to trunk) Having the processes in place helps avoid conflicts in the first place. Put these in place on projects you manage as a code of conduct (for those projects) if there is no overarching requirement for it. - comment as not an answer to the question itself.

For the long-term, I'd suggest pushing for everyone to code their functions to rely on interface contracts rather than implementation details. That way, if developer X changes internal details inside, it shouldn't break anything outside of it as long as it fulfills its contract responsibilities.

You sound very inexperienced. As others have explained your overall system isn't in place yet to develop code. Really this is yet another software question that is not relevant to the workplace site.