Comment 12 for bug 316247

- When a user accepts several tags, which item will be used? It will now choose an arbitrary one. I think this can only work if there's also some kind of popup to choose between a set of applicable updates, as in another RFE.

I don't understand this comment. You can already put multiple items in an appcast, and it will chose the newest one which meets the system requirements. The tag would behave the same way. IE: I have 3 listed (from newest to oldest). The newest requires 10.5 and has beta tag. The second requires 10.5 and has no tag. The third has no tags or requirements. On 10.4 the third is selected. On 10.5 with no tags set in the appcast, the second is selected. On 10.5 with the beta tag enabled in code, the first is selected.

- It is not backward compatible. Note that (older) Sparkle versions without this feature don't know how to deal with appcasts using this feature (and they do get them!). And you cannot have the app updated before it checks ;-) I really think this should be a showstopper, as I see no easy fix.

The same can be said about system minimum version for older Sparkle versions. IMHO, that is a larger problem than the tag system, as that can result in installing software that might not even launch as opposed to something like beta software. If anything, this is an argument to put it in 1.5, as you might as well only have to deal with this issue with one release, but I digress. This feature is opt-in, so developers can handle is however they want.

- I don't see much of a simplification here. It just replaces one potentially confusing part (using different feedURLs) with another (using a confusing "tag", which doesn't have an obvious meaning). Beware of feature bloat, as it leads to confusion!

Having to maintain a single appcast is a huge simplification. When you release beta software, add a new item with a beta tag; when it's released just remove that item. This is a lot easier to maintain than having a separate beta feed that sometimes points to beta software, sometimes points to the same as released. Over time with multiple feeds, you might end up with a lot of separate appcast to maintain forever (different types of betas); with tags you can just remove the item and you're still good. 3 lines of documentation would fully explain the tag functionality, and it's opt-in. I agree with avoiding feature bloat fully, but a single, multipurpose tag is not at all bloaty - in fact, it might avoid in the future adding more specific built-in features regarding filtering; it's generic enough to be used for many different uses. Plus regarding confusion, this will not be user-facing, only developer-facing.