Firestore schema versioning and backward compatibi

Firestore a NOSQL is a Document oriented database. Now how to manage versioning of the data as I use it with Firebase SDK and Android applications?

For e.g. let's say I have a JSON schema that I launch with my 1.0.0version of my android app. Later 1.0.1 comes up where I have to add some extra fields for the newer documents. Since I changed the structure to have additional information, it only applies to new documents.

Therefore, using this logic, I can see my Android application must be able to deal with all versions of JSON tree if used against this project I create in the firebase console with Firestore. But this can be very painful right, that I have carry the deadweight of backward compatibility endlessly? Is there a way to have some sort of version like in protobuf or something the android app can send to firestore server side so that automatically we can do something to prevent crashes on the android app when it sees new fields?

See also this thread, the kind of problem the engineer has posted. You can end up with this kind of problem as new fields get discovered in your JSON tree by the android app Add new field or change the structure on all Firestore documents

Any suggestions for how we should go about this?

In node.js architecture we handle this with default-> v1.1/update or default-> v1.0/update, that way we can manage the routes.

But for android+firebase SKD-> talking to Firestore NOSQL, how do I manage the versioning of the json schema.

We come up to next versioning with Firestore:

prefer additive changes, backward compatible -> keeping structure as it was, but with adding new fields (that can be ignored by old mobile clients)
in case it is impossible, and we are doing backward incompatible change: we have a collection in Firestore, called 'versioning', where store clients with allowed versions. Then mobile application on lunch fetch this version for current platform and compare version from configuration with stored in Firestore - if version is less then min allowed, force upgrade required, else if version less then current, we recommend updating the client, otherwise all is fine.