
Ask HN: App and Cloud versioning strategies? - Jonovono
Hi. At work we have a separate App and cloud team.<p>Something that has come up recently is how to do the versioning between these two teams.<p>Some things that have arisen and we arn&#x27;t sure the best solution. Maybe some here have gone through already.<p>1. Adding non breaking changes to the cloud api (like adding a new key to a response). What&#x27;s your process for ensuring that all the older app versions don&#x27;t break with this change? Obviously if it&#x27;s written properly to ignore unknown fields it should be fine and you have unit tests to verify that it&#x27;s ok. Just wondering if that can always be assumed?<p>2. Doing data schema changes. We store data sent from the cloud in storage on the device. It basically stays there until the cloud increments the &#x27;schema version&#x27; which tells the app that it needs to be reloaded (maybe that object now  contains new fields so the local cache needs to be reloaded). This should be done automatically I think. The client could keep checking the modified timestamp for every object and replace ?<p>This one is also like we need good offline&#x2F;online handling. We looked into using firebase but that would be too expensive. I wonder if there is a accepted way of doing this?<p>Any thoughts or suggested reading on this topic would be helpful!<p>Thanks.
======
BjoernKW
I suppose the answer to 1. is some combination of API versioning and unit
testing. Cloud APIs aren't different from usual, local APIs in that respect.
How do you deal with breaking changes in libraries? Unit testing and using
your IDE's capabilities to detect signature / protocol changes.

As for 2. I'm not sure if there's a generally accepted best practice for this
but again I think this isn't much different from more traditional scenarios. A
workable approach probably is using migrations, i.e. the app checks via an API
endpoint if there are new migrations (using a timestamp) and if there are
downloads and applies those.

