Is side-by-side install of different Mac release versions of same app possible/practical?

[BeauRX]

Wondering if anyone has done a side-by-side install of different versions of the same app e.g. APh 1.9 and APh 1.10 from Affinity Store?

It seems that GPU/Metal development is proving tough for multiple vendors (I don't have Adobe products but have read same on LuLa) and the errors are often catastrophic.

If not, I sure would support actively testing a short beta of final build since beta and release and coexist side-by-side. It would be better being stuck or having to revert. In my own SW experience I found coordinated short focused betas much more effective than long ones where customers mostly did not participate actively. Thx

 

[LondonSquirrel]

27 minutes ago, BeauRX said:

Wondering if anyone has done a side-by-side install of different versions of the same app e.g. APh 1.9 and APh 1.10 from Affinity Store?

Not from the App store. For APub, which I downloaded direct, yes. It works fine. I usually keep the last version which I know works as well as the updated version. If you want to know why it works, look up 'rpath' or 'runtime path'.

I have toyed with keeping versions of the App store versions of AD and APhoto. It should be easy enough to do. Just rename the application in Finder. This may mean downloading the application twice. Alternatively, when the updates come out, just rename the current version, (or even duplicate it). But I use these less than APub so it's not such a big deal for me.

Note: this is not supported by Affinity. YMMV. It may all go wrong for you.

[walt.farrell]

55 minutes ago, LondonSquirrel said:

For APub, which I downloaded direct, yes. It works fine. I usually keep the last version which I know works as well as the updated version. If you want to know why it works, look up 'rpath' or 'runtime path'.

Wouldn't both versions end up using the same "user" directory that holds Assets, Brushes, and various other settings? If so, that's quite risky as those internal files sometimes change format and content across release changes (1.8 to 1.9, 1.9 to 1.10, etc.). Running the uplevel release would upgrade the files, and then running to he downlevel regressed would have the files in a format it wouldn't understand. That can lead to crashes, or to the downlevel release replacing the file(s) with factory-reset versions, and losing changes you've made.

[LondonSquirrel]

1 minute ago, walt.farrell said:

Wouldn't both versions end up using the same "user" directory that holds Assets, Brushes, and various other settings?

Quite possibly. Which is exactly why I wrote this is not supported and it may all go wrong. I am only writing from my experience, not as a recommendation.

I am actually very careful with my files and backups, and I have continual independent backups going continuously. I have never had to revert an Affinity file but I am confident that I can go back to any previous version, including any assets and settings and anything buried deep in ~/Library and so on, without problems.

BeauRX does however raise an important point about testing new versions alongside old versions. I do sometimes see in the forums that 'such and such version doesn't work, how do I go back to the old one?', and the like. There's a few such posts 'live' at present. This is the method I use to avoid exactly this sort of problem. In the past, with other software, I have been bitten by things suddenly breaking with updates and have had to revert.

Once again, YMMV. And to be clear, this is not a recommendation nor is it supported. If you go down this route, you should know what you are doing and have 100% reliable backups.

[walt.farrell]

2 hours ago, LondonSquirrel said:

BeauRX does however raise an important point about testing new versions alongside old versions. I do sometimes see in the forums that 'such and such version doesn't work, how do I go back to the old one?', and the like. There's a few such posts 'live' at present. This is the method I use to avoid exactly this sort of problem. In the past, with other software, I have been bitten by things suddenly breaking with updates and have had to revert.

That's why Serif provides the beta versions. Anyone who owns the retail version can install the beta of the next release and test it, and see if their workflow will have problems. But this is, I think, at least twice now where the final build has not been put through the customer beta for at least one of the applications.

And note, too, that some issues arise because of sandboxing restrictions provided by the Mac App Store or Windows (for the Microsoft Store), and those can't be beta tested by us.

I don't know whether the current problems crept in during the builds that weren't beta tested, or whether they're just workflows that no customers chose to beta test, or didn't notice, or whether they're related to sandboxing.

I do know that one of them (Publisher Resource Manager shows Missing for Linked .afdesign documents) was present in the final customer beta build (as I just tested that) but it's not a workflow I use often and I hadn't tested it earlier. So at least one was there and could have been caught, and perhaps if more users were trying the betas it would have been.