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.
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/elsebranches (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.