Comment 20 for bug 316247

Yup, the solution would be a "paid2.x" tag (or something similar). Of course this is a bit complex, but it is a complex situation. Honestly I can't think of a simpler solution to this.

In your example, if the appcast supported multiple tags per appcast item, there could be items in a single appcast for 1.1 (no tag), 2.1 ("paid2.x" tag), and 2.5b ("paid2.x" tag and "beta" tag). If the user is running 1.0 and hasn't paid, the "paid2.x" tag won't be set so it'll grab 1.1 (regardless if the "beta" tag is set in the app). If the 1.0 user has paid, but doesn't have the "beta" tag enabled, it'll grab 2.1. And so forth for 2.5b2. Now if the user is running 2.0, the "paid2.x" tag will always be set, so it will grab 2.1 or 2.5b depending on the "beta" flag.

IMHO this is highly extensible and solves the problem of multiple tags without being too complicated, and only requires the addition of supporting multiple tags in an appcast item (plus the currently posted patch).