2

This is a scenario I have seen:

I have a shared library with code that fetches data from an api. Let's call this ApiProvider. Currently this ApiProvider is in version 1.1.1 and is currently pointing to the v1 version of my REST api. Then I have to update my ApiProvider to point to my v2 REST api and do some code changes in the way it talks to the api. I update the version of ApiProvider to be 2.0.0.

I have multiple shared components libraries and some of them use the ApiProvider. Let's say that the library shared-component-a uses the ApiProvider and I update its version to be the latest one (2.0.0) and then I bump the version of shared-component-a to be the next major version.

shared-component-b library uses shared-component-a library, the one that had the major update. In shared-components-b I have to update the version of shared-component-a to the latest one, but besides that nothing else changes in shared-component-b. So now my question is: should shared-component-b have a major or minor update?

// before
web-app
|-- shared-component-b (2.1.0)
|---- shared-component-a (2.1.0)
|------ api-provider (1.1.1)

// after
web-app
|-- shared-component-b (???)
|---- shared-component-a (3.0.0)
|------ api-provider (2.0.0)

Any input is welcome!

Thank you in advance!

4

Semantic versioning is about the API that the versioned entity exposes. Assuming that there are no incompatible API changes or addition of functionality in a backwards compatible manner, I would expect that shared-component-b would have its patch version incremented by 1 - that is, it would go from 2.1.0 to 2.1.1. This would indicate to consumers (in web-app) that the functionality provided by and API to shared-component-b has not changed and the risk of updating to a newer version should be relatively low.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.