As an addon developer I find Anki’s versioning a bit… unfortunate. Specifically, I have a problem with Anki not using patch versioning.
A lot of users are stuck with older versions of Anki since they need addons that do not support later Anki versions. So I also want to support a few older versions. The problem with this is, from Anki version numbers I can’t tell which versions I should test against and which I should ignore.
For instance, Anki 2.1.49 was a “stable” version. Anki 2.1.52 was just released. Two versions ago 2.1.50 was released. All of these, from the numbes, appear equal. But 2.1.50 was quite broken and is unlikely to be used by anyone, and 2.1.51 is unlikely to be used too. So how do I know to test against Anki 2.1.49 and 2.1.52 only?
If Anki was using SemVer, 2.1.50 could be released as something like 87.0.0, 2.1.51 as 87.0.1 and 2.1.52 as 87.0.2. 2.1.49 would have been something like 86.0.5 maybe. So I would know to test against 86.0.5 and 87.0.2 only, and when a new patch arrives, it would have the form 87.0.3 and then I know that I should abandon testing with 87.0.2 and test with 87.0.3 instead.
(I used a large major version number since Anki changes its API a lot. However, since Anki’s “API” are ill-defined and oftentimes I have to use private methods, I have no big opinion on how major version should work.)
Is the current versioning scheme useful for anyone? Why not change it?
I did see that topic, but I don’t think it ever mentions the problem with patches. Since this is a separate issue, I made a new topic.
Also I don’t see the answer of how the current system is useful. It seems that the argument is that 2.0 → 2.1 was a rather big change, what with Python version change and Qt version change from 4 to 5, and recent changes such as Qt version change to 6 is smaller, and so doesn’t warrant minor version change? I’m not sure how this makes the current versioning system useful?
I also see this part
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.
A bit curious as to how this can be a problem? Is this about the fields such as Supports: Anki 2.1. [ ] to [ ]? I don’t suppose the change to this should be much more difficult than changing it to Supports: Anki [ ] to [ ] and having users enter the full version?
It was not an argument for a specific approach, it was just pointing out that the 2.0->2.1 move was bigger.
AnkiWeb currently only stores patch versions in integer fields, and updating all the version-handling code will take time. It will get done at one point, but it’s not a top priority right now.
If 2.1.45+ corresponded to 21.7.0~21.7.4 and 2.1.50+ to 22.4.0~22.4.4, there’s more semantic info than what we currently have where only the patch number is used.
I see, but the value of the year and month info depends on the release strategy. If you align releases with the calendar (major updates with new year, minor releases with starting months and patches any time), then I’d agree that it has more meaning.
Knowing the date by itself is not as useful as being able to differentiate small from big changes, right?
Large updates would get a date bump, minor updates would get a patch bump. It’s effectively major+patch, with no separate minor number, with a year/month instead of an incrementing number.
would at least allow to differentiate between small and big updates
The last big change was Qt5 → Qt6 I guess. As for me, this was a very minor change, supporting Qt6 even without Qt5 compatibility mode was a breeze. However the same version introduced changes in how Editor draws buttons, which made do a lot of work fixing that.
Point is, I wouldn’t be able to tell from the version how much work it would be. I have to get into “private” Anki machinery in order to display an editor button with text. Since a patch is allowed to change anything inner, it means every teeny-tiny version can break things. This situation can be remedied somewhat but I don’t see how this can be fixed completely at this point.
minor updates would get a patch bump
I just hope that this will only happen for backwards-compatble bugfixes. As in, given 2022.5.1 and 2022.5.2, I would only ever want to use the latter and not the former. This would be very nice .
I think it’s not just about how much information is theoretically present in the versioning, but how much there really is. If you use semver, but that you are unable to keep up with its “interface”, then you are delivering less information than if you used Tex versioning, because you are actually providing false information.
Having something that is, in theory, less good, but in practice more manageable can still increase the information.
.