1958119 - [IAN] Allow targeting (include and exclude) to match multiple versions

Status: RESOLVED WONTFIX

(Thunderbird :: General, task)

Description

[Toby Pilling [:tobyp]]

Ideally, it should be possible to target on multiple versions using something similar to a "like", rather than having to specify each release explicitly.

As an example, we want to have a specific notification for users who upgrade to ESR140. Currently, we need to target this using multiple specific values in targeting.include.versions (e.g. ["140.0.0", "140.0.1", "140.1.0", etc] ) and cannot simply set targeting.include.versions = ["140"]

It would be better if the targeting could match ["140.", "128."] or something that will allow the notifications to be more easily configured.

Comment 1

[Martin Giger [:freaktechnik]]

I think if we want to allow targeting version ranges, we should use two new keys, min_version (inclusive) and max_version (exclusive) inside the profile object. That way your example of "versions": ["140.", "128."] would be [{ ... "min_version": "140.0a1", "max_version": "141.0a1" }, { ... "min_version": "128.0a1", "max_version": "129.0a1" }].

I'm mostly suggesting this because it allows us to leverage existing functions that are well tested for exactly these kinds of uses: https://searchfox.org/mozilla-central/source/xpcom/base/nsIVersionComparator.idl available as Services.vc.compare.

Comment 2

[Toby Pilling [:tobyp]]

If we replace versions with version_min and version_max, we'll need to bump the schema from 2.0 to 3.0 and maintain two versions of the notifications file on the server, right?

If this is preferred, I can begin this conversation with the services team.

Comment 3

[Martin Giger [:freaktechnik]]

I'm not suggesting to replace, but to add. I can still see reasons that we'd want to target exact builds.

I don't think that'd need a schema bump then, since old clients can safely consume it. However, old clients would of course just ignore these new instructions, so they'd show notifications limited by such criteria. So a schema bump might still be useful.

Comment 4

[Andrei Hajdukewycz [:sancus]]

My original intent for these fields was that they would be a "contains" match by default, not an exact match. So "140" would match any version containing "140".

That can cause some unfortunate ambiguities in edge cases but I think the general idea is still good, and maybe we could introduce the "*" wildcard operator for all targeting fields. So "140.*" would cover all ESR versions past and future. "en*" would cover all English locales, etc.

Comment 5

[Toby Pilling [:tobyp]]

Considering the small number of minor changes involved in updating the YAML on the few occasions that we're using versions to target, it isn't worthwhile to make these changes in the client and server.