QuPath App Version label on macOS about qupath

[petebankhead]

Hi @Edwinterb this seems to be a duplicate of #1250 with a potential fix.

I'm not sure if/how the proposed fix could be incorporated into the build process using jpackage though. Is that something you've explored at all?

There's a description of the build process at https://qupath.readthedocs.io/en/0.4/docs/reference/building.html - it automatically generates the installers, and jpackage doesn't like versions that start with 0.

[Edwinterb]

Hi @petebankhead, apologies for creating this new enhancement without properly searching exisintg ones!
I have read up the links and the previous request and I understand the predicament you have now. Unfortunately I do not have any experience with jpackage to be able to offer any insights, other than of course changing the verion to 1.4.4, but I appreciate this may not be desired.
Perhaps the package could be created using Xcode in future? Again not something I have much experience with as I am not a developer, but it may also aid you in future if there is a desire to sign and notorize future releases. Gatekeeper on macOS Ventura is a bit more agreesive with unsigned apps and may notify users on first launch that the app is damaged. This can be bypassed by right clicking and selecting Open. This is when we deploy the Qupath pkg to managed devices using MDM tools:

[petebankhead]

Thanks @Edwinterb yes, we used to provide a dmg but recent macOS releases thwarted that - they were particularly unhappy if this was downloaded, and seemed to work extra hard to make it non-runnable. The pkg has proven the 'least painful' distribution method, and the right-click trick is documented here.

I do most of my development on a Mac, so suffer the pain directly.

jpackage integrates well with our build tools, and seems to be the 'official' way to make installers for Java applications. I'm not good enough with XCode, build tools or GitHub Actions to figure out a way to piece together an alternative that gives an opportunity to squeeze in a proper version number.

@alanocallaghan would have a better chance of figuring it out than I do, but I don't see how I can possibly mention it to him when he's already embroiled in other macOS-related woes - without actually being a Mac user.

[alanocallaghan]

For the macos-latest builds on github actions, it might suffice to add a step (assuming we set the version in an env variable somehow):

     - name: Set version number
       if: matrix.platform == 'macos-latest'
       shell: bash
       run: defaults write /Applications/QuPath.app/Contents/Info.plist CFBundleShortVersionString {{env.version}}

and (remembering to) manually run the same command locally for the mac m1 builds, until GitHub finally releases m1 runners into the wild.

[petebankhead]

Is this able to add it to the .pkg, or only the ..app?

If it's only the .app, we could build that separately with jpackage but then need to somehow get it properly into a .pkg (which might not be that hard, but I don't know...).

Actually, now that I think of it, it might be doable in Gradle as well - which has the benefit of knowing the version.

Will try to look into it, but not sure if I'll have time before the next release.

[alanocallaghan]

Don't really know the distinction between .pkg and .app, it'd be the output of ./gradlew jpackage -P git-commit=true -P package=installer mergedJavadoc. But if possible within gradle that'd be much easier

[petebankhead]

The .pkg wraps up the .app in an installer. I think jpackage will create the .app first, then the .pkg if required - but I don't think it gives space in between to do anything useful.

I've never used defaults (didn't know it existed...) so don't know if it requires the .app.

We use package=installer to get the .pkg because otherwise I think the .app has all sorts of scary quarantine flags set that mean it can't be launched without recursively removing them all (at least that's my vague memory of what happened, I may well be misremembering). The flags only occurred when downloading - so on my local build I thought all was fine...

[petebankhead]

I've attempted a fix at #1344 - it seems to be working on my computer, so if no new problems arise the correct version should be available in the next release.

[alanocallaghan]

Should definitely mention this in the release notes, because v0.5+ will be newer than v1 (until the "real" v1 happens)

[petebankhead]

Fair enough - I've also gone rogue in including the version number in the name, e.g. QuPath-0.5.5.app.

It's not the Mac way to do things, but I figure there is a strong possibility people will want to have multiple versions installed (or at least I do... and suspect everyone should).

[alanocallaghan]

Sensible

That would be a downside of the deb/rpm approach on Linux, unless we do some similar shenanigans with application names

[petebankhead]

In the end I had to revert the changes that 'fixed' this because they ended up causing much bigger problems, which only emerged when preparing the next release candidate.

More details at #1379

[Edwinterb]

hey @petebankhead were you using the defaults command to update the version number? Not sure if you noticed my edit to the original post here:
Edit: you will need to change the permissions of the file after running above command as it will be 600 and should be 664
sudo chmod 664 /Applications/QuPath.app/Contents/Info.plist

Perhaps the plist was seen as damaged after modifying it and the file then had the incorrect permissions?

[petebankhead]

I tried defaults first, but quickly ran into the permissions problem - so switched to PlistBuddy as suggested at #1250

That seemed to work, but it turned out to still fail in confusing and subtle ways after downloading & installing. After very many hours spent trying to sort it out, I had to admit defeat because it was blocking the release - details are at #1379