Affinity Photo 2 for macOS - (2.5.2)

[Patrick Connor]

We are pleased to announce an update for the macOS release of Affinity Photo 2, version 2.5.2

The changes in Affinity Photo 2 for macOS 2.5.2 are listed in this FAQ forum thread:

Those are the changes made since the last release Affinity Photo 2 for macOS (2.5.0)

 

To get notified when any new releases are made please follow the latest releases thread by clicking here

UPDATING TO THIS VERSION (which is free for all V2 users)

The software version can be seen on the splash screen and the About dialog (in application menu, Affinity Photo > About).

If you’ve purchased from the Mac App Store— updates are done automatically next time you run your software after it is available in the Mac App Store. If this does not happen for you, open the Mac App Store app and go to the Updates page and then Store > Reload page or press CMD+R. This should hopefully force the update to show. Apple sometimes phase roll outs around the world which can mean it may take up to 72 hours for your update to be available.

If you’ve purchased from the Affinity Store— each time you start the software it will check for updates and offer to download and install any available update, or in the application main menu there is an option Check for Updates. You can download the latest installer by logging into the affinity store here and find the order in your account and use the "download" button in there. Alternatively, this new release (and previous versions of Affinity Photo for macOS) can be downloaded from this link (that installer is NOT for Mac app store purchases, which update through the Mac App Store).

[Patrick Connor]

All Readers

This thread is solely for commenting on this announcement.

Please do not post bugs or problems that you find when using this version of the software in this thread, instead make a new thread in the V2 Bugs on macOS section and questions about usage go in the Desktop Questions forum.

[acsr]

Since it is neither a bug or a feature related comment, I take the shameless opportunity to put this comment here. Feel free to move it around to a better place.

Confusing version strings | beta matches regular version

Today I downloaded the 2.5.2 files and was confused by the beta download having the exact same version string, small size differs only (the icon?) same creation date and the DMG Download missing the version string in the download file.

I take this as a bit confusing and would suggest the Affinity team to view this naming convention from the outside experience. I am usually not always taking such detailled notes during significant changes of my setup. But this time it found my attention.

Thanks for the other work! Have a nice day

[Patrick Connor]

For Beta builds we release lots of different 2.5.0.xxx builds so the 4th number is used to distinguish which one of the many betas you are using. There will only ever be ONE definitive 2.5.0 release and one 2.5.1 release and one 2.5.2 release build, so the 4th number serves no real purpose and when we have provided it customers have expressed confusion. 

The final beta release (2.5.2.2486) should always match the versions number in the release build 2.5.2 [2486], which we do as the final fixes and changes are just as important to beta users as release version users.

 

[acsr]

24 minutes ago, Patrick Connor said:

For Beta builds we release lots of different 2.5.0.xxx builds so the 4th number is used to distinguish which one of the many betas you are using.

got this, but never saw it during install.

25 minutes ago, Patrick Connor said:

customers have expressed confusion. 

We had confusion because of missing it . Confusion can be avoided by explicit clearness. (see below)
«You should make things as simple as possible, but not simpler.» – A.E. 

26 minutes ago, Patrick Connor said:

The final beta release (2.5.2.2486) should always match the versions number in the release build 2.5.2 [2486], which we do as the final fixes and changes are just as important to beta users as release version users.

Important aspect, but confusing without the build ID.

I would expect after a release, you are back to development. But yes, you are already internally working on 2.5.3 only as well as alpha, beta and release candidates. Who are not familiar with naming conventions may end up in confusion.

Suggestion: Add some explicit secondary text close to the beta download link (I do not use automatic updates) making clear, this is a version matching the release version (as long as this is true).

In my case I could download a 2.5.2 release and we had this 2.5.2 beta link. Could have been a mistake.

It is usual for developers entering development of the next release, to make a build with the simple commit text "bump minor version to 2.5.3, back to development", but this is not suitable for public betas, since until next beta release there are internal alphas etc.

My suggestion: A plain text message added to the link explaining the state. This can help a lot. Git hooks can help to automate this  
Example:

Quote

2.5.2 beta final (matching 2.5.2 release)
Purpose of a beta matching the release:  If you are working beta only, we make sure you get the final release state as well.

 

[moniuch]

I'm more bothered by the release notes reading experience than the versioning scheme (seems pretty regular semver, it's just that the major version is included in the product name). Every time I land on this sort of post I'm not sure which link to click in order to see the concise bullet points list. Way too much noise.

Couldn't we have this journey more... ekhm... modern? By that I mean a page where you specify: the product, two comparison versions and platform, and get the list? And of course. when you use query string in the URL those fields would be populated automatically so this linked could be used in the in-app update notifications.