What should I do if I update my own dependencies without changing the public API?

Use your best judgment. ... it MAY be best to perform a MAJOR version release ...

For Java the best judgment can be more precise.

1. Transitive dependencies are part of public API.

Let C be user's project, A be our library and d be a transitive dependency. And let's say that we want to use a newer version of d - d' - in our new version of A'. In Java application with the single class path there are two options: either transitive dependency jar be available on the user's classpath in the version d', or it'll be available in the previous version d (ceteris paribus). In the former case other modules/libraries that were expecting older version d would suffer from incompatibility, in the latter case our library would suffer. The degree of change is exactly equal to the degree of version change of d (MAJOR, MINOR, PATCH). Thus d is effectively part of the public API of our library A.

2. Hence whenever we change a transitive dependency version to some degree, we should change the version of our project to corresponding degree.

• MAJOR change in d => increment MAJOR part of version A;
• MINOR change in d => increment MINOR part of version A;
• PATCH change in d => increment PATCH part of version A.

Of course, we suppose that d follows semver recommendations.

Proposal: Amend this FAQ section and add a special notice for Java (as an important domain for semver).

For Java (and similar environments) transitive dependencies are part of the public API and thus the version of the user library SHOULD be incremented to the same degree:

• for MAJOR change in transitive dependency we SHOULD increment MAJOR part of our version,
• for MINOR change in transitive dependency we SHOULD increment MINOR part of our version,
• for PATCH change in transitive dependency we SHOULD increment PATCH part of our version.

If a few dependencies are being changed, only the highest degree is required to be incremented.