If an add-on has all it's current (signed) versions blocked, and is disabled to prevent future versions, we define it as is_all_versions=True in the API, and use that to show "Versions blocked: all versions" on the blocked detail page; if not, we list the versions, like "Versions blocked: 1.2, 2.3, 456.789." and so on.

The question for @abyrne-moz / @wagnerand is: how should soft blocked versions affect this evaluation. If an add-on has all it's signed versions soft-blocked (or a mix of hard and soft), and is disabled, should it be is_all_versions=True? There's some dependency here on #15016 and if you want to differentiate the scenarios in the copy too.

but if going that route note that v4 API needs to stay backwards-compatible.

After writing and testing the shims - and for min_version/max_version too that are unused by frontend - ... I noticed that /blocklist is a v5 only API oh, v4 and v5, but not v3, nevermind

how should soft blocked versions affect this evaluation. If an add-on has all it's signed versions soft-blocked (or a mix of hard and soft), and is disabled, should it be is_all_versions=True?

on slack @abyrne-moz said

I would say YES to this question. Because a user will come to the "soft block" version of the AMO blocked (The one with the soft block copy), and if they're all soft-blocked then we should mention it.