Each Microservice should be versioned separately

We know Microservices map one-to-one to a Bounded Context (typically). Because a microservice encloses all concepts and technical details relevant to the Bounded Context, it can be designed, deployed, and hosted independently.

For this reason, Microservices don't share execution space or data with other microservices. They are loosely coupled and only interact with other services over a published API (or via events).

When they do interact, it is crucial that a service is not locked to a specific version of another. This is where forward compatibility and backward compatibility come into play. Being compatible allows services to change and grow independently of one another.

It follows that the version of a microservice can be assigned independently of others. One microservice can be undergoing rapid version increments because it is under active development, while another is be stable and seldom change. It does not make sense to try to sync the versions of all microservices to be the same.

Versions are also how a microservice gets a chance to update and catch up with a newer version of another service. It can upgrade when, and only if, it needs to access the functionality available in the more recent version.

It is helpful to use a common versioning strategy across services, though. For example, semantic versioning works best in such scenarios because we can auto-detect updates across microservices. A service can continue to work with the newer version of a service (compatibility FTW!) and update itself at a later point in time, only if necessary.