I realized too late that one node upgraded to 0.14. But since I didnt want to go through the trouble and downgrade it, I accepted it is not accessible until the new Android versions comes to F-Droid and I upgrade the rest of my cluster.
However, this created conflicts with all since modified files and even worse, recreated files I deleted or moved. This happened from 0.12 to 0.13 as well which was a huge pain since I had to go through all my files to find out which should have been removed already. This time I was prepared and set up an inotify-wait to get a list of all modifications. But still, its a huge, unnecessary pain…
Is this going to change in future versions?
Is there a better way to deal with it if I only realize the different protocols when syncing isn’t working anymore? I really don’t want to go through this again…
It happens because resolving conflicts is what we need the database for, and when there are incompatible changes to the database format that isn’t possible.
The good news is that the main change in 0.14 was to move to an extensible protocol (and, somewhat, database format) to avoid this in the future.
Should we have to break it anyway, which I honestly hope we won’t, the workaround is to do the upgrade when things are in sync.
In the release notes here and on GitHub, but so far we’ve only made major releases when there is breakage (apart from some very early ones). So the fact that it is a major release is a huge warning sign.
Good to know this has been addressed.