Ankidroid and Anki FSRS version will not always match

[Expertium]

Even so, we can’t force all users to update Anki on all devices simultaneously. That would eliminate the problem, but it’s just not possible. Which means that we need to think of some kind of failsafe in case FSRS versions don’t match. But past releases of Anki have no way of dealing with future versions of FSRS, unless we sneakily add a dormant version of FSRS and wait for most users to update, or unless we attach a time machine to Anki.

[Keks]

Why not do it the same way as with the V3 scheduler or FSRS. When a new incompatible version of FSRS is released, the user is given the option to switch to it with a warning that support is required on all devices.

[Danika_Dakika]

@L.M.Sherlock

But it feels weird that some parameters are unused but still kept in the list.

@Expertium

If the number of parameters is different between two versions, it automatically makes them incompatible.

I’m not trying to wind y’all up, I swear! But waaaaay back at the beginning of this thread – which seemed like it was predicting a non-problem – I gave a full-throated defense of the devs being capable of dealing with this situtation.

@Danika_Dakika

But the devs could ensure backward/forward compatibility in about a dozen different ways, right? Why would we be concerned that they would choose not to do that?

@Danika_Dakika

These just seem like the sorts of things done in any responsibly managed software dev cycle (which all of the Anki devs have demonstrated they care about). For example –

I still don’t understand why it’s impossible. Obviously, me understanding it isn’t a prerequisite to anything – but I’m hoping there’s something better out there than it feeling weird or being automatically incompatible, when planning for how users will experience this sort of change.

[Expertium]

But the devs could ensure backward/forward compatibility in about a dozen different ways, right?

But how exactly?

1. Release a new version of Anki, AnkiMobile and AnkiDroid on the same day, same hour, same minute. Problem: users can still forget to update or somehow not realize that they need to update on all devices.
2. Just throw an error if, say, AnkiDroid receives invalid (for the current version of FSRS) parameters from Anki. Problem: a flood of “FSRS broke after syncing” posts.
3. If parameters are invalid, automatically switch to the older version of FSRS. For example, if Anki supports FSRS v5 but AnkiDroid doesn’t, and the user uses Anki and clicks “Sync”, after syncing AnkiDroid would fall back to FSRS-4.5. Problem: users will be forcefully downgraded to an older version of FSRS.

@Danika_Dakika

Dev action: The current 17 slots are sacrosanct, and any new/different parameters have to be added at the end (even if that means that newly-generated parameter sets will have 0.0000 or null values in some of the old/moth-balled slots).

@Danika_Dakika

Dev action: (1) Hard-code an appropriate default value on that parameter that will work for any user, and (2) add enough transition warnings/guidance that you’ll catch most users to update their parameters.

Both only work if past releases of Anki have information about future releases. In other words, releases before FSRS v5 would have been integrated into Anki must have some code related to a release with FSRS v5. That’s what makes forward compatibility such a tremendous pain in the rear. Either you need to sacrifice a great deal of flexibility (for example, the number of parameters is always 17, no more, no less), or you need to know exactly what the future release will look like and preemptively incorporate measures to deal with that into the present-day release.

[Danika_Dakika]

@Expertium

Both only work if past releases of Anki have information about future releases.

That’s where I keep getting lost!

The idea behind both of my back-of-the-envelope suggestions was that those would only require changes on the v5 side, because goal was protecting the v-4.5 side. [Although I do see that putting a null/0 value in the deprecated parameter would be a problem, so how about just have it inherit the old unused value and then stay in sync with AnkiDroid? Or even have the v5 parameters be separate from the 4.5 parameters?]

Many of us have experienced using the following combinations, which all worked, without those past releases having information about those future releases (at least in the beginning), right?

AnkiDroid using SM-2 v2	with	AnkiDesktop using SM-2 v3
AnkiDroid using SM-2 v3	with	AnkiDesktop using custom/advanced FSRS
AnkiDroid using SM-2 v3	with	AnkiDesktop using built-in FSRS

But you’re saying that this [fictionalized for effect] is impossible?

AnkiDroid using FSRS-4.5 & 17 4.5 parameters, w[0]-w[16]	with	AnkiDesktop using FSRS v5 & 19 v5 parameters, w[0]-w[16], but ignoring w[12] and using w[17] instead, plus brand new w[18] and w[19]

I feel like I’m asking, “why is it impossible?” and the answer is, “because.” If my understanding gap comes from the fact that all of my coding knowledge is antiquated, and I have no idea how anything is implemented in Anki, then I suppose we’re done. But if feels like you’re explaining it to me with words that I understand and they just never arrive at a logical reason. Or else maybe I’m just not meant to understand this one.

[Expertium]

1. SM-2 v2 with SM-2 v3: works ok because v3 doesn’t fundamentally change the formulas and settings. Sure, it handles time zones and card sorting order differently, but the math of ease and interval lengths is the same.

2. SM-2 v3 with FSRS: bad because the version that doesn’t support FSRS will revert to SM-2. Ideally, we don’t want to force users to use an older algorithm (and we also don’t want to make them use the Helper add-on as a crutch, that’s just a poorly designed ecosystem). FSRS-4.5 with FSRS v5 has the same problem. Also, the fact that SM-2 and FSRS use completely different parameters helps somewhat. FSRS-4.5 and FSRS v5 would be “competing” for the same parameter field.

In my previous comment, I said:

@Expertium

If parameters are invalid, automatically switch to the older version of FSRS. For example, if Anki supports FSRS v5 but AnkiDroid doesn’t, and the user uses Anki and clicks “Sync”, after syncing AnkiDroid would fall back to FSRS-4.5. Problem: users will be forcefully downgraded to an older version of FSRS.

This isn’t “end of the world” level of bad, but on the sliding scale from “great” to “end of the world”, it’s a bit too far from “great”. Throwing an error about mismatching versions would be even further from “great”, because that would break the user’s studying routine.

[Danika_Dakika]

@Expertium

FSRS-4.5 and FSRS v5 would be “competing” for the same parameter field.

Why do they have to be?

[Expertium]

They would overwrite each other since only one set of parameters can be used at any given time. Unless you want to have two different fields, which would be very confusing for users, and would also require incorporating information about future releases in the current release.

[Danika_Dakika]

So, Anki isn’t capable of displaying one set of Options for a user on v5 and a different set of Options for a user on 4.5? Because I know it’s capable of displaying different Options for a user on SM-2 than a user on FSRS (and customizing the Options displayed based on add-ons, etc.). This seems not-that-different.

[Expertium]

Sure, but that would make it more complex and, therefore, more confusing for the average user. FSRS is already very confusing for most people, so it’s best to not add any more complexity.

[Danika_Dakika]

It sounds like no matter what is done, a user is going to have to go through a manual upgrade-to-FSRS v5 process (for one thing, because they can’t use it until they have new-and-improved parameters) – whether they trigger it, or it’s offered to them after an update. That means no one will get to v5 without knowing about it – and getting ample warnings about the fact that this will be a slightly different FSRS than they are using on AnkiDroid, and the parameters will be different, but that everything is otherwise compatible.

If they upgrade, then when AnkiDroid is ready for v5, it will know to check for an existing v5 parameter set and to shift to using that seamlessly (maybe a one-time “you’ve just been upgraded to v5” box).

If they don’t want things to be different across platforms, they can opt-out of the upgrade and wait until AnkiDroid is ready for v5. When that happens, AnkiDroid, seeing no existing v5 parameter set, can drive the upgrade from it’s side.

For a user, that doesn’t sound any more confusing or complex than any other upgrade. We will lose a certain share of users who refuse to read things on the screen, but that’s unavoidable.