We had discussions about how to keep compatibility, these were the possible solutions proposed:
- Wait until users of an incompatible version deplete (this is just delaying breaking compatibility until it has low impact)
- Upgrade on partitioned topic only once a positive acknowledgment is received that the other end has a compatible version (this can be carried on in contact requests / messages). This approach currently is limited by the fact that multiple devices might be running different versions (i.e desktop most users still use the released version of the app).
Protocol negotiation does not work well in our case given the asynchronous, mostly offline nature of communications, not to mention the fact that communication are really multi-cast (public key), rather than device-to-device.
As a matter of fact, we haven’t released this version, so we are still in time to backtrack (it’s just a flag in the config), and take a deeper look.
In general, I think we should also note that the first PR received little to no reviews after a week of bothering people, and the discuss post had only two contributors, although that was mentioned in the dev meetings, on status and core-chat stands up.
When we had any discussion, most of the people didn’t go further than saying "don’t do it’ or providing not so relevant examples (i.e synchronous online apps without multi-device support).
None of these are helping us move towards a solution, although they are worth mentioning and more constructive engagement would be appreciated.
If we want to grow as a team, we should also start making people accountable for the lack of engagement in critical moments (i.e. discussion about partition topic/compatibility, which in my opinion were fairly visible), instead of waiting for someone to act and criticize post-mortem (which is not a post-mortem, as we haven’t quite pulled the trigger yet, so come forward!)