WhatsApp: fix version string; improve zap stanza

[pantheraleo-7]

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

---

Currently, Homebrew shows a 4 component version string for WhatsApp, e.g. 2.25.34.11. The leading component 2 appears to be private to WhatsApp's internal usage, and only required in the download url.

Sparkle: <sparkle:shortVersionString>25.34.11</sparkle:shortVersionString>

App Store:

[bevanjkay]

We still need to capture the 2. as part of the version, because what happens if it changes?
A better consideration may be to have a two-part version in the Cask file.
25.34.11,2.25.24.11

[krehel]

This doesn't seem to be causing issues and is working fine, inclined to leave as-is.

[pantheraleo-7]

what happens if it changes?

This is akin to asking "what happens if any part of the download URL changes?", e.g. branch=master -> branch=main. The leading 2 is not part of the version string, as evident from the sparkle appcast & App Store metadata. It is an implementation detail. In case we are proven wrong, we can always revert back to the previous approach but we should at least first try to have correct versioning.

BTW the current livecheck is hacky to say the least as there's no need to regex items when the app supports standard sparkle appcast schema.

This doesn't seem to be causing issues and is working fine

Of course it is, as far as installation and updates are concerned. And it will still work that way after the changes. The fix is about the incorrect version that we have in our metadata.

[p-linnane]

Agreed with the other maintainers that there's no reason to change this.

[pantheraleo-7]

Do as you will, but just for the record:

• It is causing issues. To me as an end-user, and other mid-level downstream users of brew API. Just because I chose to open a pull request instead of an issue doesn't mean the incorrect version isn't causing problems.
• "This doesn't seem to be causing issues" is a non-argument to begin with.

[p-linnane]

You've failed to articulate any concrete issue this is causing. We aren't going to accept a hardcoded URL change without good reasoning.

If you can provide that, maybe we can implement the suggestion @bevanjkay made above.