Release strategy and semantic versioning for shared libraries in a microservices architecture

Really the "sharedness" of the libraries is inconsequential. It's whether or not the change you make breaks/is required by the individual microservices.

eg

1. I upgrade a shared helper library to fix a vunerablity. But the overall functionality is unchanged

Here the various services can carry on as they are, you can upgrade over time as you like without issue.

2. I add a new field to a shared Domain Model.

Here the change is likely to be backwards compatible, after testing, you can roll out to microservices that want to use the new field first and the rest as and when.

You say :

A concrete issue we face is that any change of a domain object in the shared library requires updating the dependency version in every consuming microservice

But consuming microservices should handle an extra field in json fine and just ignore it. Are you somehow forcing the requirement with validation? You should allow v1.1 to be compatible with v1 for example.

3. Change to a cross cutting concern, auth or serialization

Here the change will break the interoperability of services, you need to operate both old and new versions of each microservice at the same time, first roll out v2, then gradually switch functions over to v2, then switch off v1

You can use routing and version headers to achieve a seamless transition. If you have automated deployments you should prob code them to do this as standard.

This is a key benefit of microservices, you must be able to change out a single microservice and this requires that you have version routing. Do not sleep on this even though most of the time you wont need it.

However, In all these cases you would have the same problem without a shared library, you would just be duplicating code and have to manually code the update on each service.

A properly versioned shared library makes to process easier rather than harder and lets you identify where services have not been updated.

on a microservices-based system

based on Semantic Versioning (SemVer)

This ain't going to scale unless the backward compatibility concerns are dumped. Even backward compatible microservices-based system doesn't scale or it scales to "big ball of mud".

When the versioning depends on 3rd party/parties versions release cadence is meaningless therefore either decouple the versioning from service dependencies versioning and set your release cadence according to followed development methodology or forget about own release cadence and use the release cadence of 3rd party/parties dependencies that in case of multiple dependencies it's going to be the sum of release cadences of each dependency.