Match CFBundleShortVersionString with Warp > About > version

[naschenbrenner]

Discord username (optional)

No response

Describe the solution you'd like?

Myself and many other Mac Admins in enterprise and education utilize Installomator to elegantly automate updates for various applications. I'd like to create a label for Warp as I have several clients whose developers utilize Warp (and admittedly myself as well), however presently I cannot as the versioning differs between what the app reports and what CFBundleShortVersionString within the Info.plist report. I understand Warp has a built in auto-update mechanic, but for those in enterprise we cannot always wait for our users to restart the app or authorize the update themself, but using Installomator and an MDM such as Jamf we can force these updates as they become available. Happy to provide additionally details if needed.

Is your feature request related to a problem? Please describe.

It's frustrating that one of my most used applications cannot be included in the most common workflow we deploy to customers for updates.

Additional context

No response

How important is this feature to you?

3

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[dannyneira]

Thanks for this feature request @naschenbrenner !

To anyone else interested in this feature, please add a 👍 to the original post at the top to signal that you want this feature, and subscribe if you'd like to be notified.

[MrCoBalt]

Giving this a bump since we have devs requesting Warp as well and we primarily tell them to manually install it into ~/Applications (since they run without admin privs most of the time and Warp's auto-updater triggers admin prompts when in /Applications —a fun separate issue!)

With the different variations in what the app is reporting for version, etc. trying for a central deployment and update method will require either an overly-burdensome manual method, or some extensive/fragile customization & scripting…

By way of example, the latest version downloaded today reports:

• CFBundleShortVersionString: 0.1.0
• CFBundleVersion: 20240820.081825
• Actual download link which doesn't match either value above: https://releases.warp.dev/stable/v0.2024.08.20.08.02.stable_00/Warp.dmg

All of this makes it increasingly difficult to check what is actually installed on our endpoints, or push new versions, and definitely makes us hesitant to embrace the software further by signing up for a Team plan or whatnot 😞

[jefflloyd]

Hey there @naschenbrenner ! Sorry for the radio silence - I posted a larger comment over here to MrCoBalt if you wanna take a look, but tl;dr I'm looking into addressing this now. I've got a version working where a Warp version like v0.2025.01.22.08.02.stable_03 will turn into a CFBundleShortVersionString of 0.202501220802.3 - a little out of the ordinary since we don't follow the major/minor/patch semver format, but it's deterministic for a particular Warp version. Still has to go through code review but please let me know if this would work for you!

[naschenbrenner]

Thanks for the update, while this approach isn’t ideal, adding a few extra lines of shell script to accommodate it should be trivial on my end. Anything that brings us closer to being able to monitor and enable auto-updating in a managed environment is a step in the right direction, so I really appreciate you looking into this. Warp has been a fantastic tool, and I’d love to see it integrate more seamlessly into enterprise workflows as MrCoBalt laid out. Let me know if there’s anything I can do to help test or provide more feedback on!

[jefflloyd]

For sure! Can you explain more about why the approach isn't ideal? Is it because you'd have to parse the CFBundleShortVersionString to relate it back to Warp's version of its version (heh)?

Something that just popped into my head is - I could also add a WarpVersion key, whose value exactly the format that Warp uses in its releases/URLs. If you have flexibility over what key you're looking at, then maybe this would be a better option? Unfortunately Apple doesn't give us the option to put our own version in CFBundleShortVersionString 😔

[naschenbrenner]

Yeah, that’s exactly what we’re doing. Adding a separate key would work perfectly though, since Installomator allows us to specify which key in Info.plist to reference for the installed version. With that in place, I can structure the label like this:

warp)
    name="Warp"
    type="dmg"
    downloadURL="https://app.warp.dev/download?package=dmg"
    appNewVersion=$(curl -fs "https://app.warp.dev/download?package=dmg" | grep -o 'v[0-9]\.[0-9]\{4\}\.[0-9]\{2\}\.[0-9]\{2\}\.[0-9]\{2\}\.[0-9]\{2\}\.stable_[0-9]\{2\}')
    expectedTeamID="2BBY89MBSN"
    versionKey="WarpVersion"
    ;;

This would make it much easier to integrate Warp into our update workflows without extra parsing. Appreciate you working on finding a solution that works for everyone! 😊

[naschenbrenner]

Thanks so much for adding the WarpVersion key to Info.plist, it’s been really helpful for keeping versioning consistent. A Warp label was later added to the Installomator project that used CFBundleShortVersionString, but I've submitted PR #2536 to update it so it now takes advantage of WarpVersion.

[jefflloyd]

Ah my bad for not circling back to this once it launched! Glad you're finding use from it :)