{"comment":{"created_at":"2011-10-23T16:35:31Z","body":"***Andy Matuschak (andymatuschak)** wrote on 2009-04-14:*\n\nI've put some thought into this problem, and I'm not sure this is the\nbest way to do it in the end. There are some tags for which it makes\nsense to attach semantic meaning, like \"paid,\" which is another big\nproblem for a lot of Sparkle's clients (though not Transmission, of\ncourse!)\n\nLlike: you want people using 3.0b3 to get notified of their free update\nto 3.0 (to thank them for testing), but you don't want people using 2.5\nto get that. Futhermore, what if you want to issue a critical security\nupdate to 2.5 (call it 2.5.1) that they should get, but 3.0 shouldn't\nsee that update?\n\nI think you need a graph, basically. I was thinking posets with labels.\nLabels could be \"sticky\" or not, potentially applying to incident edges\ncoming from a vertex with that label. This would be useful for the\n\"paid\" label.\n\nSo between these hesitations and my continued promise that 1.5 is\nfeature-frozen, I think this needs to wait.\n\nIt's maybe not a bad idea to get this kind of thing out there, though.\nAnd you can! Just branch Sparkle and apply your changes; it'll appear in\nSparkle's main launchpad page for other people to merge in if they like.","updated_at":"2011-10-23T16:35:31Z","url":"https://api.github.com/repos/andymatuschak/TestMigration/issues/comments/2496174","id":2496174,"user":{"gravatar_id":"5a37f99aa1daf8c27aaa81e4f019484d","avatar_url":"https://secure.gravatar.com/avatar/5a37f99aa1daf8c27aaa81e4f019484d?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","url":"https://api.github.com/users/andymatuschak","id":2771,"login":"andymatuschak"}},"action":"created","issue":{"number":32,"created_at":"2011-10-23T16:35:22Z","pull_request":{"diff_url":null,"patch_url":null,"html_url":null},"body":"***livings124 (livings124)** [reported (on Launchpad)](https://bugs.launchpad.net/sparkle/+bug/316247) on' 2009-01-12:*\n\nI'm not sure if \"Answers\" or here is the best place to add feature\nrequests, so I'm guessing it's here.\n\nIt would be useful to have multiple updates listed in a single appcast\nfile, with some sort of key separating them. This would be similar to\nhow it works now with minimum version numbers.\n\nFor an example, I could have 2 updates, one with no key and one with the\nkey \"beta\". There would be some sort of method (delegate maybe?) to\nspecify all the valid keys (as an array most likely). If no keys are\nspecified, the update with the \"beta\" key would be ignored and only the\nother would be considered. If one of the keys specified in the code is\n\"beta\", however, both would be considered, and the one with the higher\nversion number would be used. This would simplify things greatly for\nusers that want to support optional updates for betas, etc.; it's easier\nto maintain and feels less hacky than having multiple feeds that have to\nbe synchronized.","comments":17,"title":"Add option to have multiple updates in a single appcast that can be selectively chosen","updated_at":"2011-10-23T16:35:32Z","url":"https://api.github.com/repos/andymatuschak/TestMigration/issues/32","id":2027330,"assignee":null,"milestone":null,"closed_at":null,"user":{"gravatar_id":"5a37f99aa1daf8c27aaa81e4f019484d","avatar_url":"https://secure.gravatar.com/avatar/5a37f99aa1daf8c27aaa81e4f019484d?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","url":"https://api.github.com/users/andymatuschak","id":2771,"login":"andymatuschak"},"html_url":"https://github.com/andymatuschak/TestMigration/issues/32","labels":[],"state":"open"},"legacy":{"issue_id":2027330,"comment_id":2496174}}