Currently, mongos sends the collection version as part of the shard's moveChunk/splitChunk requests and MongoD versions 3.2 and earlier check that the collection version matches in the beginning of the operation and then include it as part of the applyOps command that they issue against the config server.

This check on the collection version effectively serializes all metadata operations for the same collection, even though they might be for different chunks. It seems much more reasonable to send the version of the chunks being modified instead of the entire collection's version. In addition, with parallel migrations available in 3.4 we can no longer use the collection version when committing the migration because it may change when multiple migrations commit at once.

The road to deprecation of the collectionVersion field should be:

• 3.2 - mongos sends only the collectionVersion and mongod only understands and checks the collectionVersion;
• 3.4 - mongos sends both collectionVersion and individual chunkVersion; on mongod, if collectionVersion is present, it only checks that the epoch matches; if chunkVersion is present, checks both the version and the epoch and includes both in the applyOps command against the config server;
• 3.6 - mongos sends only chunkVersion; mongod only interprets the chunkVersion and fails if it is missing;

This requires changes on the config server and on the shard itself.

NOTE: The mongos invocation of the mergeChunks command intentionally does not include either of these fields, because (a) it contains a [min, max) range of chunks to be merged and it is impractical to send version for entry from the range due to the unbounded nature of such information and (b) it is a rare enough and cheap enough operation that having it fail due to collectionVersion mismatch at applyOps time is an acceptable tradeoff.