Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide on a policy for maintaining compatibility with older versions of Anki #152

Open
aplaice opened this issue Nov 25, 2021 · 0 comments

Comments

@aplaice
Copy link
Collaborator

aplaice commented Nov 25, 2021

When/how long?

Anki's internals change relatively frequently, which requires CrowdAnki to be changed in turn. Without also keeping the previous behaviour in some sort of if/else branches (which might quickly lead to a forest of complexity), compatibility with earlier versions of Anki is lost.

Fortunately, Ankiweb allows the maintainer of the addon to specify the Anki versions that the given version of the addon is compatible with, and for each Anki version, the last compatible version of the addon is used. Hence, users using older versions of Anki still have access to old versions of CrowdAnki.

However, bug fixes and new features from the later versions of CrowdAnki aren't available to these users. This is particularly problematic if there were major bugs.

My gut feeling would be to generally drop compatibility except when there were major-ish bugs, (and drop compatibility soon after fixing the bugs/releasing).

From what I understand from Stvad's previous decisions, he's strongly in favour of dropping compatibility/not maintaining compatibility shims (presumably because they're a maintenance nightmare).


Alternatively, if we had robust (per Anki version!) integration testing, and a way of keeping the "shims" separate from the main codebase (see below), we could try to maintain compatibility indefinitely. This is obviously a pipe dream, for now, though. :)

How?

From a code-structure perspective, having the compatibility shims in separate modules/files, perhaps labelled by Anki version(s), where they'd, say, override Anki's (or CrowdAnki's) behaviour for the older versions of Anki, would have the advantage that the "compatibility shims" wouldn't clutter up the main codebase and would be very easy to remove.

Alternatively, an approach of "feature detection", like in #151 (and similarly to (AFAIU) best practice in web development), could be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant