Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for channels #1879

merged 12 commits into from Jun 29, 2021

Add support for channels #1879

merged 12 commits into from Jun 29, 2021


Copy link

Add support for channels, mainly intended for supporting beta or nightly updates in the same appcast feed.

You specify a channel on an appcast item, and the updater will only look for updates on that channel if the delegate says it's allowed to. No specified channel means the appcast item is on the default channel, which updaters always have access to.

This is only intended to support versions that branch off to different channels and that eventually converge back to the default channel. It's not for maintaining completely parallel trains; separate appcast feeds still fit that use case (or the use case of migrating to newer appcast features, like this one).

This implementation is simple and almost identical to the patch proposed in #51 for Transmission back in the day.

I needed to also fix the logic that assumed no updates in an appcast meant there was something wrong with the feed. This may happen for various reasons, but in this case we must assume the user is just up to date.

Probably my last enhancement / missing gap to 2.x, then I intend to look into tooling (sparkle-cli, generate_appcast) and docs..

Fixes #51


  • My change is being tested and reviewed against the Sparkle 2.x branch. New changes must be developed on the 2.x development branch first.
  • My change is being backported to master branch (Sparkle 1.x). Please create a separate pull request for 1.x, should it be backported. Note 1.x is feature frozen and is only taking bug fixes, localization updates, and critical OS adoption enhancements.
  • I have reviewed and commented my code, particularly in hard-to-understand areas.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • My change is or requires a documentation or localization update


I tested and verified my change by using one or multiple of these methods:

  • Sparkle Test App
  • Unit Tests
  • My own app
  • Other - sparkle-cli

Tested adding beta channel to test app and made sure updates were picked (or not picked) appropriately based on the implemented delegate method.
Added unit tests.
Tested sparkle-cli support for channels on running test app.

macOS version tested: 11.5 Beta (20G5042c)

@zorgiepoo zorgiepoo merged commit eecc480 into 2.x Jun 29, 2021
@zorgiepoo zorgiepoo deleted the channels branch June 29, 2021 02:57
Copy link

jeff-h commented Sep 21, 2021

I'm wondering if there's any way to only show beta release notes to those using my beta channel (I'm using external release notes)?

If not, I wonder if it would make sense in the appcast to have a separate <sparkle:releaseNotesLink> for each channel?

Copy link
Member Author

zorgiepoo commented Sep 22, 2021

Since the appcast item will be only be available to those who subscribe to the beta channel can’t you just use a different beta release notes file for them? People on the default channel shouldn’t see them.

Copy link

jeff-h commented Sep 22, 2021

Sorry, I was tricked by the fact my generated appcast.xml only had one sparkle:releaseNotesLink, so I didn't realise it would work in other items also. Thanks for your time helping a newbie :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

Add option to have multiple updates in a single appcast that can be selectively chosen
3 participants