Adds standard user driver delegate method for responding to Version History button

[billymeltdown]

Adds a new delegate method to the SPUStandardUserDriver protocol for responding to the Version History button with custom behavior. Standard user driver first checks for the presence of the delegate method, then falls back to opening the release notes link as the button action as before.

As discussed in #1877

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 (please specify)

I did a make release of my fork with my changes, dropped that Sparkle.framework into my app in place of current version, and checked that delegate method is called correctly. Then removed delegate method and confirmed previous behavior worked as expected.

macOS version tested: 11.6

[billymeltdown]

I'm not really sure why the French translation commit is included in this pull request -- I haven't used this github feature before, apologies if I did it wrong.

[zorgiepoo]

The GitHub pull request approach works off of branches. So people normally create a branch (from 2.x in this case) containing only the commits they want to push back into main (2.x in this case) branch on the main repo. And the pull request tracks that branch. Then if the changes get merged in 2.x, you can cleanly pull the changes into your own 2.x without their being divergence (in case something differs in the middle).

[zorgiepoo]

LGTM barring two small comments.

[billymeltdown]

I've just re-tested these edits in my own app to verify the changes.

[zorgiepoo]

Thank you. I may do some minor commenting tweaks, but looks good.

[aonez]

That was quick!

[billymeltdown]

@aonez Happy to help, even if it's just a little bit 😄

Modify away @zorgiepoo! I tried to ape the comments style from the rest of the project but figured they would need work.

[zorgiepoo]

Any little help is good :).

@aonez let me know if you're able to adjust SUAppcastItem.m / SPUStandardUserDriver.m for the fullReleaseNotesLink change, otherwise I may be able to get to it over the weekend. I've been thinking I think it's still good to provide that option in the feed.

[aonez]

Sure I had other things but I’ll try to do it today

…

On Thu, 4 Nov 2021 at 07:04, Zorg ***@***.***> wrote: Any little help is good :). @aonez <https://github.com/aonez> let me know if you're able to adjust SUAppcastItem.m / SPUStandardUserDriver.m for the fullReleaseNotesLink change, otherwise I may be able to get to it over the weekend. I've been thinking I think it's still good to provide that option in the feed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1989 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADVHIY7D2LGX37LFGAAY2TUKIV77ANCNFSM5G7MQ5EQ> .

[aonez]

@zorgiepoo I've made a pull. It lacks generate_appcast code, let's follow there.