endnote 22

[jabenninghoff]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• 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.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new <cask> worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

[jabenninghoff]

EndNote 2025 (22.0.0.21347) has been released on https://endnote.com. As with the release of EndNote 21 (#147759), the livecheck URL for EndNote 22, https://download.endnote.com/updates/22.0/EN22MacUpdates.xml is live but does not yet contain any version information.

$ wget -O- 'https://download.endnote.com/updates/22.0/EN22MacUpdates.xml'
--2025-04-25 15:03:07--  https://download.endnote.com/updates/22.0/EN22MacUpdates.xml
Resolving download.endnote.com (download.endnote.com)... 3.166.118.72, 3.166.118.124, 3.166.118.63, ...
Connecting to download.endnote.com (download.endnote.com)|3.166.118.72|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 70 [application/xml]
Saving to: ‘STDOUT’

-                                  0%[                                                         ]       0  --.-KB/s               <updates>
<data1></data1>
<data2></data2>
<data3>0</data3>
</updates>
-                                100%[========================================================>]      70  --.-KB/s    in 0s      

2025-04-25 15:03:07 (16.7 MB/s) - written to stdout [70/70]

[khipp]

Thank you, @jabenninghoff! Could you please link the source for the new version and the updated download URL? The livecheck URL for EndNote 21 still points to 21.5.0.20846 as the current release version.

[jabenninghoff]

@khipp, unfortunately, when Clarivate releases a new major version of EndNote, the new version and download URLs are only available on the support page which won't work with livecheck. I've implemented a workaround similar to what was done for the release of EndNote 21 (#147759).

[samford]

How we approach this depends on whether the existing XML file for version 21 is updated to include versions beyond 22.0.0.0. If it will only ever reference 22.0.0.0, then this wouldn't ever be able tell us that a new version is available and we could end up being stuck on 22.0.0.0 until someone identifies a new version outside of livecheck and manually updates the cask.

If that's the case, then I think our only option would be to maintain the existing livecheck block and allow it to fail (skipping livecheck on CI for this PR), assuming it will eventually return a new version when the next update appears. If we're not sure, this may be the safer approach. It's not ideal but the upstream setup isn't ideal either.

[jabenninghoff]

Looking at the available XML files, https://download.endnote.com/updates/#{version.major}.0/EN#{version.major}MacUpdates.xml with versions 22, 21, 20, 19, 18, and 17:

• EndNote 2025 (version 22.0.0.0) is listed in each of the XML files
• EndNote 21 (version 21.0.0.0) is also listed in the version 20 XML file
• The EN22 XML file exists but is mostly empty
• Each XML file is updated when a new minor version is released

Given that, should I leave the livecheck url as-is? The livecheck will fail until the first update for EndNote 2025 is released. If that's the preferred choice, I'll add a commit for that to this PR.

[samford]

Given that, should I leave the livecheck url as-is? The livecheck will fail until the first update for EndNote 2025 is released.

Thanks for checking the older files. Yes, considering that 21.0.0.0 is present in the XML file for 20 but was never modified for subsequent 21 versions, the existing approach seems like the only option that will ensure the check will return a new version when it appears. However, I think it still makes sense to not omit html entries (so we can catch new major version releases), so we just need to switch the url back.

In terms of handling the livecheck failure for new major versions, we can either skip livecheck for major version PRs like this or we could modify the strategy block to selectively return the cask version if the XML file doesn't contain update information and the cask version is a new major version (i.e., ending with .0.0.0). We generally discourage falling back to the cask version in a strategy block because the check will appear to be working as expected even if it's failing due to an unexpected upstream change. Selectively doing this for new major versions may be slightly less risky but it could become a problem if upstream decides to change the XML structure when creating a new major version.

I tend to be of the opinion that it's better to fail because that's something we can easily see and track. For example, when a new major version is released, we would see the failing check, look at the cask file and see the explanatory comment above the livecheck block, and check the XML file to confirm there's no update information. If everything seems fine, we would probably ignore the failure (as something expected) but maybe periodically check the XML file again to confirm that there's not an update that we're missing due to a structural change.

Though not ideal, I think skipping livecheck for new major version PRs and allowing the check to fail until a new version appears may be the most reasonable approach. I've added a suggestion with a comment to explain the situation, so we know this is an expected failure. [For what it's worth, we generally only have explanatory comments before the livecheck block or within strategy blocks but not elsewhere in the livecheck block.]

[samford]

Thinking about this some more, one issue that I didn't consider before is that hardcoding 2025 throughout the cask will become a problem when the next major version is released. When the livecheck block returns 23.0.0.0 as the newest version, that will presumably correspond to something other than 2025. Updating the version wouldn't affect the url, so the cask would continue to install the newest 22.x version unless the url is manually updated in the version bump PR.

Including 2025 in the version (e.g., 22.0.0.0,2025) and interpolating it throughout the cask would resolve this but the challenge is how can livecheck reliably identify the 2025 part of the version. We could match the EN2025 part of the webPage value for the major version build item in XML files like EN21MacUpdates.xml but this isn't true for the other build items (i.e., for normal updates).

I think we could technically fetch the download page in the strategy block and match 2025 from the EndNote2025Installer.dmg filename on the page, combining that with the version from the XML file. However, this could lead to a mismatch between the version like 2025 and 22.0.0.0 if both sources aren't updated at the same time. Unless there's a source of version information that reliably provides both version parts for every release, that may be the best we can do if we want to surface major version updates.

The alternative is to leave the livecheck block as it is (i.e., restoring the early return to exclude items with an html type), so livecheck doesn't surface new major versions. This would require someone to manually identify a new major version and update the cask like you're doing here. This isn't ideal but it would at least ensure that the cask is properly updated for a new major version.

It seems like there are going to be shortcomings no matter how we approach this and it's just a matter of what variety of pain we prefer.

[jabenninghoff]

@samford, as I understand it, we can't use the download page for the livecheck because it is hydrated with javascript. Since version 17, Clarivate has changed the branding of EndNote 3 times (X7, X8, X9, 20, 21, 2025) and each major release has required manual changes to the cask. Major releases happen every 2-3 years, and it's difficult to guess how the next release will be branded, so it will probably require manual changes regardless.

Given that, I'd suggest the best option is to keep the cask as-is, which we expect will work for new minor releases, and will let us know when a new major release is available.

[samford]

we can't use the download page for the livecheck because it is hydrated with javascript

Ahh, I hadn't tested it yet but I'm seeing that it uses a gnarly POST request that we can't reasonably replicate.

Major releases happen every 2-3 years, and it's difficult to guess how the next release will be branded, so it will probably require manual changes regardless.

I agree that requiring manual changes to the cask with major version updates makes sense but I want to make sure that a major version update won't pass CI and be able to be merged unless/until the product/marketing version (e.g., X9, 2025, etc.) is also updated. It would be too easy for a maintainer to quickly glance at the version change, think it looks fine, and merge it without realizing that the version isn't correct with respect to the file used in the url.

I thought about this some more and what we could do is include the product version as the second part of the cask version (i.e., 22.0.0.0,2025), interpolate version.csv.second in the url and container nested: strings, and modify the livecheck strategy block to append the product version to upstream versions matching the current major version but omit it for others. With that setup, livecheck would omit the current product version for a new major version (e.g., 23.0.0.0) and that version value would cause the cask to fail CI because version.csv.second would be nil. This would allow livecheck to surface a new major version but we would need to manually identify the new product version and add it to the cask version for the update to work.

If that makes sense to you, I can push these changes to the PR branch. Unfortunately I can't add a suggestion for the livecheck strategy block because GitHub doesn't support creating a suggestion that also spans unmodified lines.

[jabenninghoff]

@samford that all makes sense to me! Please do push the changes, thanks!!

[samford]

Thanks for your help and patience, @jabenninghoff! Someone else will need to approve this (as I'm the last pusher) but I think this should be good to go now.