I have few libraries, some of them depend on another. So for eg:
A 1.0.0 No dependencies
B 1.0.0 Depends ON: A 1.0.0
Question is:
If i release A with 1.0.1 and this release is backward compatible with 1.0.0 should i release B?
This can depend a lot on the specifics of the code and how the artifacts are deployed, but in general, you need to release B to make the code changes in A visible.
<dependency> on that artifact. That means that the client also has a transitive dependency on A, but at the specific version that was expressed in the <dependency> in B. Taking your example, the client has a dependency on B 1.0.0, which itself has a dependency on A 1.0.0, so the client will pick up A 1.0.0 transitively. In order to publish a bug fix in A to this client, you need to release B 1.0.1 with its <dependency> on A updated to point to A 1.0.1.<dependency> used by the web application is shipped inside the lib directory of the built war. In order to publish a bug fix in A to this web application, you need to release B 1.0.1 with its <dependency> on A updated to point to A 1.0.1.In the first example, (client depends on B as a jar), a possible workaround is for the client to override the version of A by adding its own explicit <dependency> on A, perhaps using a version range for flexibility to pick up the latest released version. This can cause maintenance pitfalls though, because it means the client is combining a version of A and a version of B that were not tested together as part of the B build. In general, it's preferrable to release B, but if it is difficult to release B, then this can be a viable short-term workaround.
More details on transitive dependencies and version range syntax are available here: