New Anki beta and versioning

Anki Beta Testing
1

Anki has a long history of not-so-great version numbers. :sweat_smile:

Semver is a bit of a tricky subject. From the perspective of add-ons, it’s a breaking API change, and you could argue that should make it 3.0. But that’s not really practical - because add-ons are so tightly coupled, we’d end up bumping the major version every few releases that way. So I mainly focus on what’s exposed to end users outside of add-ons. This update doesn’t change how cards are stored on disk, or require a downgrade before moving back to .48 for example.

When we upgraded to Qt5, that involved a bump to 2.1. But that was a much bigger move, as we had to transition from WebKit to WebEngine, and asynchronous JS requests, and it wasn’t feasible to support Qt4 and Qt5 in parallel. That is not the case this time - the web API is closer, and Anki still works on Qt5.

But regardless of whether it makes sense or not, it’s not a change that can be easily made at the moment, because AnkiWeb’s update and add-on handling code was hacked together while I was busy with the 2.1 work, and it wasn’t written with support for future minor versions in mind. Teaching it how to deal with semantic versions (or even just a single new minor version) will take some time, and it’s probably not something I’ll be able to get to before this release unfortunately.

@dae I wanted to follow up on this comment now that we’re a few months into this process. I know @Glutanimate and many others have also chimed in on this. I’ve spent countless hours and thrown thousands of dollars at helping update my add-ons and popular community add-ons. I want to reiterate that I think this should be a bump to 2.2. I know you mentioned that teaching anki how to deal with semantic versions may take time, but I think that time would be well spent. Rushing to deploy this update would be unfair to users and add-on authors. Nearly 1/3 of the ~60 add-ons I use and share with the community broke on the PyQt5 update and over 1/2 of them are broken on the PyQt6 version. This includes things that are “essential” such as image occlusion, heatmap, etc. (many of which owned by @glutanimate or other authors who do not have time to update things right now).

I answer many messages every day from confused users and add-on breaks are a huge portion of this. I appreciate the massive amounts of functionality updates, but I think this update needs to carefully examine the effects it will have on Anki’s user friendliness. None of the updates in this version are so massive that it’s worth rushing to publish and given the continued breakages, I think it is well worth the time to more properly set up Anki for future versioning. I don’t think anyone would complain if it takes another 6 months before this update is formally released if that also meant things were compatible and set up for a much better future. Many of us would prefer to have a much larger update twice a year than multiple smaller updates throughout.

Of course, the decision is ultimately yours, but nearly everyone I’ve talked to has expressed that they feel this should bump to 2.2. I’m happy to do a formal poll of my community if that would better help guide your decision.

7 Likes
2

(FWIW, I’m working on updating both IO and RH – IO will be out sooner, RH will take a bit more time due to more breakages. I’ll also have to figure out how to best get the RH update to people as most are on the GitHub build)

But to the general point: @dae I fully understand your concerns about having versioning follow add-on compatibility patterns too closely and the scope of the changes that would be required on AnkiWeb’s end.

However, I do still feel like this is the most natural opportunity we’ve ever had to make a cut and bump up to 2.2.0. Even setting add-on concerns aside, the changes to the editor, removal of the V1 scheduler, and native M1 compatibility to me feel significant enough to warrant a more user-visible versioning bump. And I do fully agree that moving up the versioning ladder at each major breaking add-on API change is not viable (though I do hope that things will settle and we’ll move out of this pattern at some point again). However, the scope of breakages in this update and the technology changes seem significant enough where I feel they should uniquely factor in this one time.

But to perhaps throw another thought into the discussion:

With Qt5 and Qt6 builds now coexisting, I think it’s likely that quite a few add-on authors will want to target Qt6-only going forward. Writing add-ons targeting both Qt versions can be tricky and creates quite a bit of additional testing workload that for many add-on authors is not feasible to take on. It also means that add-on authors would either have to target Qt5, creating legacy costs and relying on imperfect shims for Qt6 support against the advice of the obsoletion notices, or complicate their code with conditional logic targeting both versions.

Either way, I think this situation does create a case for add-on authors to be able to specify which Qt versions their AnkiWeb uploads/branches support. And if this is sensible and viable to tackle, then, naively, it seems reasonable to also deal with semver alongside it as both are likely to touch the same code paths.

But yeah, that’s just my two cents. I realize that there are other considerations outside the add-on ecosystem to be made and that having an Apple Silicon native build out sooner rather than later is important.

However, regardless of the exact versioning and AnkiWeb infrastructure we end up with, at baseline I would like to ask you to please give add-on authors enough time (at least a month) with a feature-frozen release candidate to test and adjust their add-ons ahead of the release.

(BTW, loved that launchpad link. I had no idea. Instant flashback to some of own versioning woes in the past :sweat_smile: )

1 Like
3

Not sure if this is sufficient for you and at all acceptable for @dae, but why not version the API separately?
If between releases the API changes (significantly), there could be a note in Anki’s update prompt (potentially only visible if add-ons are active/installed). Likewise, an API change in the newest release would be indicated on AnkiWeb.
For smaller bugfix releases in contrast, add-on users could update without hesitation. And should there be a breakage regardless, it’s likely an oversight like a missing alias that can be reported and fixed.

4

There is no big rush - it’s the end of the year and people are busy, and I think we will need at least a few more beta builds before a release candidate is even ready. By the time it’s pretty much ready to go, if the add-on situation has not improved sufficiently from what it is now, postponing the release is a possibility. In a way, that’s not fair to users either though - there are some people who don’t rely on add-ons, or use a smaller number of them that have already been ported, and they shouldn’t necessarily have to wait.

An alternative possibility is tweaking the website to direct add-on users to an older version for a while. An in-app update notice is unlikely to be set off until months after the release.

Will follow up on the other points in the next few days.

7 Likes
5

Regarding the version number, in 2.0→2.1 we had:

  • Python 2→3
  • Qt 4→5
  • QtWebKit → QtWebEngine, and all the API changes that were required to move from a synchronous to an asynchronous API.
  • Added v2 scheduler

It was a lot of work, and both Anki and add-ons took a long time to get fully updated and the issues ironed out.

This time we have added support for Qt6 and reworked the editor, and the changes are somewhat smaller in comparison - apart from the resource handling, the Qt changes are mainly a straight mapping of old names to new names, without a great deal of changed functionality.

While the “modernize Anki’s backend” project is mostly done (to the extent that such a project can ever be “done”), there is still importing/exporting to tackle, and all the compatibility shims and aliases that are currently in place will need to be removed at one point. Holding off on another stable release until the remaining parts are done and version number handling is improved would push back a release by quite a few months, and we’d lose some of the benefits of RERO that way.

I know the churn in the last two years has been frustrating at times. Thank you all for your patience, and I assure you I’m looking forward to things calming down a bit as much as the rest of you are!

Add-on authors are of course free to choose what they wish to support or not support, but I suspect Anki will need to keep supporting Qt5 for a while yet. The ARM Linux and no-systemd camps depend on a system-provided version of Qt, and as far as I’m aware that’s mainly/all Qt5 at the moment, so if we went Qt6-only, they would be unable to use the new releases. There are also various issues like slow loading of large images and a lack of tabs on macOS that some users may feel are showstoppers. There will invariably also be issues that we’re not even aware of yet, that will only crop up once a stable release is made and more people are using it.

Part of the problem is that the current code is not set up to deal with a new minor version number, and this doesn’t really help us there - new code would need to be written to handle the version change either way.

6 Likes
6

IMHO the number of complaints about new upgrades breaking old add-ons would probably be much lower if people made the effort to learn how to use the program instead of installing a zillion plugins just because they think it’s necessary.

On the other hand, I think that add-ons should be designed to add auxiliary, not core functionalities to the program. Yes, I would love to have built-in support for image occlusion and other important functionalities, but building your card collection around the functionality provided by an add-on is, by definition, not a good idea.

Anki is a very active project, and since I started using it, a few months ago, a lot of new useful and interesting features have been added to the core program, features that benefit everyone and that will continue to work in future versions of the program. Yes, compatibility with some (maybe many) older add-ons is broken, but personally, if I have to weigh up things, I would say that adding new core features is way more important than keeping compatibility with add-ons.

Just my (very personal) point of view.

4 Likes
7

I think the further you get into it, the more important a lot of these get. While not vital, they certainly make it a lot easier and user friendly. For example, you can add hyperlinks if you know the html, but the add hyperlink add-on makes things way easier. The symbols add-on is similar. For creating and organizing and updating decks, advanced browser, special fields, batch editor, etc are vital. Customize keyboard shortcuts becomes essential in many ways. Spell Checker seems like a very basic function that exists in most apps nowadays.

I could go on an on. There are at least 20-30 add-ons that add very basic functions many people will use and are mostly standard in most other applications these days.

2 Likes
8

Yes, I fully see your point, and I’m by no means saying that you’re not right, I will try to explain a little bit better my pposition, though

Before discovering Anki, I had tried a lot of flashcards methods and programs, but I always missed something important in all of them. Anki was a revelation, the program I always had looking for: every little thing I needed to do (but I always missed in other programs) was possible in Anki: Do you need a fast and powerful search system? It was there; do you need an efficient way of creating decks for custom study sessions? No problem; do you need a flexible tag / deck system to keep your crads organized? It was there; do you need to export /import your cards to an open, non proprietary format, or to synchronize your collection between different devices? Easy. Everything what I really needed (and some features I didn’t even know I needed) was already there, implemented in an intuitive and efficient way, in a completely free and open source program.

But Anki has its own terminology and particularities, and I soon realised that a certain amount of time and effort was going to be necessary in order to get the most out of the program. So I started to watch youtube videos, and some lessons I “learned” there were insistently clear: add-ons are the greatest thing in Anki, you absolutely need to install a ton of them; if you want to avoid ease hell, don’t use the “Hard” button; don’t use the “Easy” button, it doesn’t make any sense; forget the standard deck settings, they don’t work; don’t mess with the deck settings, install this plugin that will automatically do everything for you; avoid program’s updates, they will break add-ons and are pointless… In other words, the core program without add-ons was virtually unusable.

Since this didn’t fit with my first impressions of the program at all, I stopped watching youtube videos / reading reddit posts, and started reading the manual and experimenting a little bit with the program myself. After a lot of experimentation, I still have a lot to learn, but I know enough to say that some, if not all of the above statements just make no sense at all.

I see it all the time: many people install a bunch of add-ons simply because they have been told to do that. Many people use some “essential” add-ons because they don’t know that they can do exactly the same with the standard program. Many people don’t know how the program settings work simply because they haven’t read the manual. Many people think that standard settings led to “ease hell” simply because they have read it in Reddit. Many people think that learning with Anki is not effective for them because they are not using the settings that work best for them. Etc, etc, etc…

Please, don’t get me wrong, I am not saying that add-ons are pointless, on the contrary, they are one the best features of the program, adding unlimited functionality and allowing certain special needs to be met. And of course, I fully agree with the fact that some of them (image occlusion, closet or connect, to name a few) are absolutely essential for certain users, but I still think that many of the complaints about anki updates breaking the add-ons come from the fact that many people simply don’t want to read the manual and actually learn how to use the program effectively and the fact that there’s a lot of misinformation out there.

5 Likes
9

I personally disagree with your view, although I agree with you about people installing too many add-ons.

I only use a very few add-ons (approx 5), and am currently not able to update to 2.1.54 as the multi-column editor add-on is broken after 2.1.49. This is not the first time that I’ve had issues with updates and add-ons.

For me the ability to have fields arranged into multiple columns is essential for usability when adding notes, due to the sheer number of fields on some note types. I really would have preferred that Anki used a normal version numbering scheme and not put breaking changes into what most people would take to be a patch release.

The ideal way in a perfect world might be to have each Anki release to declare a python API version, javascript API version, etc (which use semantic versioning) and then have add-ons in their metadata declare which APIs they support, and that to be manifested to users as supported Anki versions in Anki Web. A warning about broken add-ons could also then be displayed when users attempt to update Anki.

10

Here’s an alternative trick Reddit - Dive into anything

1 Like