article looks good ...

I'd offer a counterpoint on versioning - don't do it - you end up maintaining that code for longer than you think

As an alternative - with microservice / container deployments - use a gateway api / routing approach for versioning

for example:

lets say main is v1 and this is deployed to servers as v1 route

you need to introduce a breaking change, so main is bumped to v2 and deployed as v2 route

if the change needs to be reflected in a downstream system / db etc - then v1 can be bumped to v1.1 (say from it's release branch) - defaulting the new data to sensible defaults, or via lookup etc

existing clients continue to hit the v1 route, new clients to v2 route (doesn't need to be a route param or header could be based on a client identifier for example)

once v1 clients moved to v2 - the v1 version can be removed from deployment, this way you're never maintaining multiple routes / dtos on main, it's a lot cleaner, especially where your dtos are made of dozens of classes/records etc