[macOS] Raise minimum supported target to 10.13

nevack commented 2 years ago

This topic have been discussed several times in other issues. Current deployment target is 10.10. This version is quite old, like 7-8 years old.

Let's raise target for the next major release. I propose to raise target to 11.0 (aka Big Sur).

It's available for Macs released in 2013 and later https://support.apple.com/kb/sp833
Distribution analytics from paid closed-sourced app https://blog.charliemonroe.net/sunsetting-support-for-older-macos-versions/
No more burden with supporting older macOS UI styles (single toolbar style, no backporting iconography) and APIs (like NSNotifications vs UserNotifications).

As an alternative or intermediate target we can stop at 10.13 (High Sierra).

It's available for Macs released in 2009 and later https://support.apple.com/kb/sp765
It's still quite new and I think we won't hurt our userbase, older systems are very rare.

CC @livings124 @ckerr @Coeur @DevilDimon @sweetppro @GaryElshaw

nevack commented 2 years ago

As of Big Sur, Apple limited macOS version tracking on the web. https://bugs.webkit.org/show_bug.cgi?id=216593

For 10.13+ current distribution is 94.92% (from StatCounter)

ckerr commented 2 years ago

@livings124 has already suggested this in another thread, so I'm also for it. Based on those blog posts's numbers, I'd be comfortable with at least High Sierra.

sweetppro commented 2 years ago

Im all for dropping support macOS 10.10. We can remove a bunch of conditional code and un-needed assets for starters, reducing the binary size will be a nice immediate benefit. Then we can slowly chip away at modernising the code such as this #3265

ckerr commented 2 years ago

@livings124 prefers moving to 11 so let's do that. If someone PRs a branch that raises the minimum to 11, I'll merge it

sweetppro commented 2 years ago

That will be a fun PR! So many deleted assets 😊

GaryElshaw commented 2 years ago

I'm for moving to 11, with a proviso that 10.13 users get included for this release, at the very least.

If we are less than a month away from beta release, and after a 2 year hiatus, if i were a 10.x user (or have been a contributor in the last 2 years on 10.x) i would be extremely pissed that i was not going to get an update.

Edit: In other words, i think 4.0 should be the end point for 10.13 and subsequent releases are for 11.x. Burning down the codebase for 10.x right now, a month out, seems a bit reactionary.

This is not insignificant: "For 10.13+ current distribution is 94.92% (from StatCounter)"

A minor personal note. One of the things i like about the majority of open source projects is that they often have a tradition of supporting older OS's and bend over backwards to accomplish backwards compatibility, whereas many of the commercial alternatives will only support the latest and/or the previous OS iteration. I could be totally wrong, but since i started contributing that did seem to be the consensus?

Coeur commented 2 years ago

At this stage, I'm against raising the minimum target until we get a new stable release compatible with macOS 10.x. There is no extra work needed to keep things as they are, and the Transmission version 3.0 is too buggy to stay the only one available for old macs.

Once Transmission 4.0 is out, then sure, we can bump the minimum version for 4.1 or 5.0. So please @ckerr , just make a 4.0 release as is, and then drop older versions support on main branch.

nevack commented 2 years ago

This issue was created to discuss our future intentions. It doesn't mean we need to make this changes right now.

I think we can safely bump target to 10.13 and stop at it for some time. Fix some deprecations, adopt View-based TableView, adopt AutoLayout.

Assets is not that a big issue, I do not see how bundling several png hurt anybody.

As for me, I'm ready to support older versions like 10.13. I even have 10.13 vm in VMWare Fusion just for that reason.

Lower target doesn't mean we can't adopt some new shiny APIs and system features. We should focus on new features we can bring to users, polishing UX and UI, fixing existing bugs.

If some new feature is important and really hard to implement on older systems - let's discuss this again, with new input we have by that time.

nevack commented 2 years ago

@GaryElshaw and @Coeur you both disliked this issue. Do you oppose the idea itself or just some specific minimum target? Do you have anything against having 10.13 as minimum?

fxcoudert commented 2 years ago

macOS Catalina (10.15) is still supported by Apple, and in Homebrew it accounts for 17% of our users, which is far from negligible. It would seem very weird not to support it.

Index | macOS Version                                 |      Count |  Percent
-----:|-----------------------------------------------|-----------:|--------:
01    | macOS Monterey (12)                           |  6,795,103 |   52.90%
02    | macOS Big Sur (11)                            |  3,281,058 |   25.54%
03    | macOS Catalina (10.15)                        |  2,152,406 |   16.76%
04    | macOS Mojave (10.14)                          |    345,824 |    2.69%
05    | macOS High Sierra (10.13)                     |    205,225 |    1.60%
06    | macOS Sierra (10.12)                          |     25,804 |    0.20%
07    | macOS (13)                                    |     23,991 |    0.19%
08    | OS X El Capitan (10.11)                       |     14,173 |    0.11%
09    | OS X Yosemite (10.10)                         |        989 |    0.01%
10    | OS X Mavericks (10.9)                         |         12 |    0.00%

mac 10.13 (High Sierra) seems to me like a reasonable value to set. It supports 32-bit systems, and was supported by Apple until November 2020.

Coeur commented 2 years ago

I believe that raising target should be done for a need, and preferably at the beginning of the development phase of a new major version. So right now, the time frame is not appropriate, and it came a bit because we never published any fix for the 3.0.0 branch (where are you 3.0.1?). Example of security fix that is absent from branch 3.x: #1638. One can still get the fix by building from sources, but very few people do that.

I'm well OK to adopt 10.13 (conservative bump, almost zero code change) or 11.0 (nice bump, allowing to remove our png files), but only after a public release of what have been fixed so far.

sweetppro commented 2 years ago

10 | OS X Mavericks (10.9) | 12 | 0.00%

12 ppl still rocking Mavericks! 👍

ile6695 commented 2 years ago

Once Transmission 4.0 is out, then sure, we can bump the minimum version for 4.1 or 5.0.

Semantic versioning requires major bump when doing backwards incompatible changes, hence the current milestone of 5.0

fxcoudert commented 2 years ago

Semantic versioning requires major bump when doing backwards incompatible changes, hence the current milestone of 5.0

Raising the minimal requirements (whether of the OS or dependencies) is not generally considered as “backwards incompatible” in the context of semantic versioning.

ckerr commented 2 years ago

Semantic versioning requires major bump when doing backwards incompatible changes, hence the current milestone of 5.0

Raising the minimal requirements (whether of the OS or dependencies) is not generally considered as “backwards incompatible” in the context of semantic versioning.

@ile6695 is right about my rationale; that's why I milestoned it for 5.0.0-beta.1.

I'd like to better understand the rationale that dropping support isn't a breaking change? If version X runs on macOS 10.10 and then version X+1 does not, wouldn't that be a breaking change? It intuitively seems like it would but I'm happy to hear the counterargument :smile_cat:

ckerr commented 2 years ago

Commenting here for visibility: there's also a PR from @fxcoudert to bump the minimum to 10.13 as a more conservative bump. Is there any consensus here on this iteration?

fxcoudert commented 2 years ago

I'd like to hear more about the rationale that dropping support isn't a breaking change?

As a Homebrew maintainer, distributing lots of software, I'm just stating factually that most projects don't consider it a breaking change. Same for dependencies: if you have to do a major version bump every time you update your requirements, then you end up doing only major version bumps :)

The semver way of labelling software is about the API and its stability, not about the ABI or binaries. It's designed to allow handling of dependencies: when project X does minor version updates, all projects that depend on X know they can still build against it, without changes. It's not about the ABI, or compatibility with OS version.

Of course, the semver definition is quite vague, so you probably can interpret it that way if you want… but it's not what most projects do. Some projects have very stable API, and therefore keep the same major version for decades. That would be really unfeasible to keep supporting 15 year old dependencies. Or it would make no sense to change the major version only for that, if the API is otherwise stable.

CyberSkull commented 2 years ago

My Mac is just before the 11 cutoff, I can run 10.15 at the most.

nevack commented 2 years ago

Fixed in https://github.com/transmission/transmission/pull/3310

sweetppro commented 1 year ago

Firefox is about to drop support for older versions of macOS, maybe we should look at this again. They will be only supporting 10.15 moving forward.

https://9to5mac.com/2023/07/04/firefox-support-older-macos/

ckerr commented 1 year ago

Chromium started removing support for <= 10.14 in their codebase two weeks ago, too:

https://chromium-review.googlesource.com/c/chromium/src/+/4629466

sweetppro commented 1 year ago

Even Apple only supports macOS 11+ https://endoflife.date/macos

nevack commented 1 year ago

Chromium started removing support for <= 10.14 in their codebase two weeks ago, too:

chromium-review.googlesource.com/c/chromium/src/+/4629466

Yep, I've also seen this at upstream. But it will roll to users in 2-3 months or so.

I don't wanna be the man holding all you from the "progress", but I do think we should collect some knowledge about:

what devices would be no longer supported. Pinging @Coeur there as we don't lose a very good contributor because just min version bump. (See: issuecomment)
what API must be migrated.
what new APIs we can implement to make Transmission more sophisticated macOS app as it is.
how hard it will be to maintain in foreseeable future.

Just let's be rational, guys, no need to rush bumping some integers for the sake of bumping. There are still deprecated things to fix, like Cell-based Table Views. See issuecomment There many perfectly capable machines that Apple decided to abandon, many of them can be used as seed boxes also.

GaryElshaw commented 1 year ago

I thought, maybe in a previous discussion(?), and i could be completely wrong, that the consensus was the 4.0.x branch would be the last to support 10.13, and 4.1.x was for anything/everything after?

tearfur commented 1 year ago

I'd like to chime in from the core library side of things. It is more about my general view regarding our minimum supported macOS version, rather than this particular bump (10.13 -> 11 or higher).

I'm quite looking forward to the C++20 bump because I can see a lot of features that will be beneficial to libtransmission. macOS minimum version is one of the main blockers of this bump as far as I can see, so I'm generally supportive for movements like this.

Having said that, many C++20 features aren't available until Xcode 15 (consteval being a major one), and that requires macOS 13.4. I don't see us making such a radical jump being a good idea either. So for now, I agree that supporting users (and especially contributers) with older, but perfectly capable macOS machines comes first.

GaryElshaw commented 1 year ago

It would be great if Antoine could chime in here, @Coeur was working on a potential macOS Swift upgrade for 4.1, and i'd love to know their thinking.

Coeur commented 1 year ago

Please kindly look at #5282: it was merged just 2.5 months prior to those comments. We moved from 10.13 to 10.14.6 following Apple's recommendation (aka RECOMMENDED_MACOSX_DEPLOYMENT_TARGET). We just have to stick to this value, which will probably just be incremented by one every year. There is no need to look at Firefox or Chromium: we're not using their API, and people may as well be using Safari on macOS.

As for our user base, I do recall one issue opened by someone who was on an older system than supported, so no need to cause extra friction with our userbase by bumping more than RECOMMENDED_MACOSX_DEPLOYMENT_TARGET unless there is a very good reason for that. Even Swift 5 support can be entirely done with that macOS version.

Coeur commented 1 year ago

Oh, but 10.14.6 three months ago was with Xcode 14.3. Then we had Xcode 15.0 beta who got released in June 2023 in the mean time. I haven't checked what is the new RECOMMENDED_MACOSX_DEPLOYMENT_TARGET. Although it will likely only be a definitive Xcode release in September 2023.

[edit] In Xcode 15.0 beta 1 (15A5160n), the value is still 10.14.6. But it may change with newer betas or with the final release. I'll try to get a newer beta in the mean time.

nevack commented 1 year ago

In Xcode 15.0 beta 1 (15A5160n), the value is still 10.14.6. But it may change with newer betas or with the final release. I'll try to get a newer beta in the mean time.

Xcode 15.0 Beta 4 RECOMMENDED_MACOSX_DEPLOYMENT_TARGET=10.14.6

tearfur commented 1 year ago

So it looks like no Mac contributer has a problem with Xcode 15, while our users can stick to macOS 10.14.6.

Sweet! That means this is not really a blocker for C++20. 😁

ckerr commented 1 year ago

For C++20 I'd be more interested / concerned in seeing how good C++20 support is on the different various platforms that we try to support, e.g. the ones on TeamCity's CI.

The reason I'm wondering is because I remember how much trouble it was adding even C++17 features e.g. std::from_chars and we stilil can't reliably use std::filesystem.

However, time has passed and so maybe newer compiler packages will have everything we need...

Coeur commented 1 year ago

I'm quite looking forward to the C++20 bump because I can see a lot of features that will be beneficial to libtransmission. macOS minimum version is one of the main blockers of this bump as far as I can see, so I'm generally supportive for movements like this.

Having said that, many C++20 features aren't available until Xcode 15 (consteval being a major one), and that requires macOS 13.4. I don't see us making such a radical jump being a good idea either. So for now, I agree that supporting users (and especially contributers) with older, but perfectly capable macOS machines comes first.

OK, I missed your comment previously, tearfur. So, two concepts:

the minimum OS version on which the compiled app "runs" (RECOMMENDED_MACOSX_DEPLOYMENT_TARGET of latest stable Xcode), which is macOS 10.14.6
the minimum OS version on which we can actually perform the compilation (currently, based on our readme, we attempt to support the same OS version, which means macOS 10.14.6 and Xcode 11.3.1.

I do not know what is the C++20 support on Xcode 11.3.1. I only have information from that page which dates from just a month ago for Xcode 14/15 support: https://developer.apple.com/xcode/cpp/

If we decide to adopt a C++ feature that isn't supported by Xcode 11.3.1, then it will mean a jump in minimal Xcode version, which will mean that compilation won't be possible anymore on macOS 10.14.6 (but running on it, yes). Think of the minimum Xcode version that you need based on the page given in previous paragraph, and then look at the "Requires" columns from: https://xcodereleases.com

If that is your wish, kindly open a new issue or discussion for visibility, specifically titled "raising minimum macOS compilation support for C++20" or similar for visibility.

Coeur commented 1 year ago

I did my best to go through the Xcode release notes to gather the below data. All of those Xcode versions support our app running on macOS 10.14.6 after compilation. But compilation itself requires a higher macOS version.

Xcode 11.3.1

Our officially supported Xcode version. Compilation on macOS 10.14.6+.

Xcode 13

Compilation on macOS 11.3+.

clang now supports C++20 likelihood attributes [[likely]] and [[unlikely]]. (78316737)

Xcode 13.3

Compilation on macOS 12.0+.

using declaration can now be used for enums, enum classes, and their members.
The compiler can deduce the size_t and ssize_t types based on new literal suffixes (uz, z), for example for (auto i = 0uz; i < vector.size(); ++i) {}.
If a lambda declaration takes no parameters, the open and close parentheses () can now be omitted in all contexts including mutable lambdas.
Duplicate attributes are now allowed by the compiler.
Any trailing whitespace after \ is non-significant.
Concatenations of string-literals with different encoding prefixes are now ill-formed, for example, auto s = L"" U"";. (89022082)

Xcode 14

Compilation on macOS 12.5+.

P0692R1 - Access checking on specializations
P0388R4 - Permit conversions to arrays of unknown bound
P1938R3 - if consteval
P1401R5 - Narrowing contextual conversions to bool
P1949R7 - C++ identifier syntax using Unicode Standard Annex 31
P2360R0 - Extend init statement to allow alias declaration (93898598)

Xcode 14.3

Compilation on macOS 13.0+.

Making std::vector constexpr P1004R2
Consistent stateful allocator propagation for operator+(basic_string) P1165R1
Support arrays in make_shared and allocate_shared P0674R1
Making std::string constexpr P0980R1
Consider ATOMIC_FLAG_INIT undeprecation LWG3659
char8_t backward compatibility remediation P1423R3
Bit-casting object representations P0476R2
Ranges P0896R4, P2415R2, P2281R1

Xcode 15

Compilation on macOS 13.4+ (based on Xcode 15 beta version).

Immediate functions (consteval) P1073R3, P1937R2
Utility functions to implement uses-allocator construction P0591R4
char8_t: A type for UTF-8 characters and strings P0482R6
nodiscard in the Library P0600R1
polymorphic_allocator<> as a vocabulary type P0339R6
Constexpr for std::complex P0415R1
Adopt source_location for C++20 P1208R6
Input Range Adaptors P1035R7
Views should not be required to be default constructible P2325R3
Smart pointer creation with default initialization P1020R1
Superior String Splitting P2210R2
basic_istream_view::iterator should not be copyable P1638R1
Output std::chrono::days with ‘d’ suffix P1650R0
Ranges adaptors for non-copyable iterators P1862R1
Rename “_default_init” Functions, Rev1 P1973R1
elements_view needs its own sentinel P1994R1
Fix istream_view P2432R1

Minimum deployment target: macOS 11.0

Those features would not allow the app to run on macOS 10.14.6 anymore. Moving to a minimum target of macOS 11.0 would also mean raising the Xcode minimum support to Xcode 12.5.1.

Synchronization library (<barrier>, <latch>, <semaphore> and notification functions on std::atomic) P1135R6
Add max() to latch and barrier P1865R1

Not supported yet by Apple

Not supported Concepts P0857R0, P2113R0, P2103R0, DR1496, DR1734, P0848R3

Coeur commented 1 year ago

Having said that, many C++20 features aren't available until Xcode 15 (consteval being a major one), and that requires macOS 13.4. I don't see us making such a radical jump being a good idea either. So for now, I agree that supporting users (and especially contributers) with older, but perfectly capable macOS machines comes first.

if consteval was in Xcode 14, and consteval in Xcode 15? Maybe that means there was partial support prior to Xcode 15. As consteval is meant to generate extra compilation errors, it might be possible to workaround that with some macro CONSTEVAL which evaluates to consteval with newer compilers and constexpr with older ones.

tearfur commented 1 year ago

Thanks @Coeur for compiling and explaining all that.

I'm not too concerned with consteval, it will at most be a minor nuisance if we used it and discovered it wasn't supported yet on some platforms.

The feature I am most interested in is the ranges library (Xcode 14.3). We have quite a few functions in the central parts of the peer communication code that allocate and deallocate temporary buffers every time it is invoked. The ranges library allows us to do away with the temporary buffers. We are talking about functions that are invoked up to twice per second, so there are some easy performance wins there.

But this is not something so major that is worth making a radical jump IMO, so I think I'll just open an issue to track the C++20 bump for now.

Coeur commented 1 year ago

Yeah, Xcode 14.3 is only supported on macOS 13.0+, which means 3 major OS upgrades from macOS 10.14.6... I would say that it will be our minimal tool in roughly 2.75 years, but it's kind of too early for now for Apple platforms. What about this C++20 range support on various Linux distributions?

[edit] Supported by all Xcode versions:

Range-based for statements with initializer P0614R1
Range constructor for std::string_view P1391R4
Range constructor for std::span P1394R4

Only supported in Xcode 14.3+:

Ranges P0896R4, P2415R2, P2281R1

Not sure precisely which one applies to our needs.

tearfur commented 1 year ago

it's kind of too early for now for Apple platforms

I see. Well this feature is a nice-to-have and not a must-have for me, so let's just leave it at that for now.

For P2415R2, these are the minimum supported versions:

Linux

GCC libstdc++ 12
Clang libc++ 14

These are the versions in the latest Debian Stable, so I think it is safe to say the support is there for Linux.

Windows:

VS 2022 17.1

https://en.cppreference.com/w/cpp/compiler_support

transmission / transmission