Improve "Outdated sync app" situations

[mueller-ma]

Today I received an update of jtxBoard on F-Droid, but the required Davx5 version isn't on F-Droid yet. Now I can't sync until the next time F-Droid publishes updates.
I suggest to improve this situation by:

1. Make jtxBoard more backwards compatible (probably too much work).
2. Wait with new jtxBoard version until the required Davx5 version is at least one week old.
3. Mention the new requirement in the changelog of jtxBoard .

[patrickunterwegs]

Hey @mueller-ma ,
I understand that this is bothering, we have been coordinating the release and still it sometimes hard just to find the time to push the button more or less at the same time. The problem is also that there is no control over when f-Droid takes the new version.

So to your points:

1. Sure a backwards compatibility would be nice, but in the cases where there was a hard dependency, it wouldn't have made sense as it fixed a major problem. Making it backwards compatible would have meant to keep a faulty logic, so it's better to force the users to update in those cases.
2. This doesn't make a difference, the dependency goes both ways.
3. I'll add the dependency now in the changelog.

[rogercreagh]

@patrickunterwegs
Having just got back online after two weeks away I have the exact same situation. Fdroid updated Jtx to v2.4.3 but only when I look at the release notes in jtx after updating do I discover that it requires Davx 4.3.3

Wouldn't it make sense if a new version requires an update to Davx5 to not release it to Fdroid until the required version of Davx5 is also available on Fdroid. It seems pointless to make a version that doesn't work available for upgrade.

Secondly is it beyond the capability of the Android install system to check what version of Davx5 is installed before allowing the update to proceed. This would be quite normal in other OSes but perhaps that is an Android problem?

Thirdly, on Fdroid there is no way of seeing the release notes before installing the update and checking on the JtxB about screen - so you have no warning that the upgrade will break your system.

Fourthly -what do I do now? What exactly happens if I try to use JtxB v 2.3.3 with Davx5 v4.3.2 ? Is it possible to downgrade JtxB back to v2.3.2 whilst awaiting the new release of Davx5 or will that break something if I have already created a new entry using v2.3.3 ? Should I simply disable Davx5 until it is upgraded and do without the sync capability? PLEASE ADVISE !!!

For the future there must be some way of warning BEFORE upgrade that there is a compatibility issue. A change that potentially breaks core functionality like sync should be a major version number change 2.3.2 -> 3.0.0 (or at least 2.3.2 -> 2.4.0 if you have a good reason not to change the major version number,but breaking changes should change the major number)

[mueller-ma]

You cannot downgrade Android apps and keep the app data. You could uninstall jtx and install the old version, but you will lose at least the app settings.

I guess I wait a few days and notify others that I cannot access the latest shared tasks.

[patrickunterwegs]

Well, jtx Board and DAVx5 were released more or less at the same time. We agreed on that. Die to a misunderstanding the tag for DAVx5 to be available for f-Droid was set a few hours later. That's how this constellation came up.

For the rest, yes, the major version could be raised, but wouldn't make a difference now. The original change that caused the dependency was a fix, not a new feature. That's why I didn't do it.

In any case, for now there are the options:

• wait until DAVx5 appears on f-Droid
• downgrade jtx Board by uninstalling it and install the previous version (but you'll lose data that is not synchronized)
• take DAVx5 from GitHub or Google Play

It's just a pain that there's no proper control over f-Droid releases, but it's like that. I'm anyway only making such dependencies when there's really no other way.

[rogercreagh]

Well if the install routine can't be made to test for dependencies then you really should (in my opinion) change the major number whenever a change (even if it is a fix) potentially breaks core functionality.