Skip to content

Add support for channels - #1879

Merged
zorgiepoo merged 12 commits into
2.xfrom
channels
Jun 29, 2021
Merged

Add support for channels#1879
zorgiepoo merged 12 commits into
2.xfrom
channels

Conversation

@zorgiepoo

Copy link
Copy Markdown
Member

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

Checklist:

  • 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

Testing

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
@jeff-h

jeff-h commented Sep 21, 2021

Copy link
Copy Markdown

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?

@zorgiepoo

zorgiepoo commented Sep 22, 2021

Copy link
Copy Markdown
Member Author

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.

@jeff-h

jeff-h commented Sep 22, 2021

Copy link
Copy Markdown

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

Labels

None yet

Projects

None yet

Development

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