-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[macOS] Raise minimum supported target to 10.13 #3302
Comments
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) |
@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. |
Im all for dropping support macOS 10.10. |
@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 |
That will be a fun PR! |
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? |
At this stage, I'm against raising the minimum target until we get a new stable release compatible with macOS 10.x. Once Transmission 4.0 is out, then sure, we can bump the minimum version for 4.1 or 5.0. |
This issue was created to discuss our future intentions. I think we can safely bump target to 10.13 and stop at it for some time. 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. Lower target doesn't mean we can't adopt some new shiny APIs and system features. 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. |
@GaryElshaw and @Coeur you both disliked this issue. |
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.
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. |
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. |
12 ppl still rocking Mavericks! 👍 |
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 😸 |
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? |
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. |
My Mac is just before the 11 cutoff, I can run 10.15 at the most. |
Fixed in #3310 |
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. |
Chromium started removing support for <= 10.14 in their codebase two weeks ago, too: https://chromium-review.googlesource.com/c/chromium/src/+/4629466 |
Even Apple only supports macOS 11+ |
Yep, I've also seen this at upstream. I don't wanna be the man holding all you from the "progress", but I do think we should collect some knowledge about:
Just let's be rational, guys, no need to rush bumping some integers for the sake of bumping. |
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? |
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 ( |
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. |
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). 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. |
Oh, but 10.14.6 three months ago was with Xcode 14.3. [edit] |
Xcode 15.0 Beta 4 |
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. 😁 |
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. However, time has passed and so maybe newer compiler packages will have everything we need... |
OK, I missed your comment previously, tearfur.
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: 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: 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. |
I did my best to go through the Xcode release notes to gather the below data. Xcode 11.3.1Our officially supported Xcode version. Xcode 13Compilation on macOS 11.3+.
Xcode 13.3Compilation on macOS 12.0+.
Xcode 14Compilation on macOS 12.5+.
Xcode 14.3Compilation on macOS 13.0+.
Xcode 15Compilation on macOS 13.4+ (based on Xcode 15 beta version).
Minimum deployment target: macOS 11.0Those 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.
Not supported yet by Apple |
|
Thanks @Coeur for compiling and explaining all that. I'm not too concerned with 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. |
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]
Only supported in Xcode 14.3+: Not sure precisely which one applies to our needs. |
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
These are the versions in the latest Debian Stable, so I think it is safe to say the support is there for Linux. Windows:
|
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).
As an alternative or intermediate target we can stop at 10.13 (High Sierra).
CC @livings124 @ckerr @Coeur @DevilDimon @sweetppro @GaryElshaw
The text was updated successfully, but these errors were encountered: