Looks good, but some thoughts:

Someone will need to keep the list up-to-date with newly appearing versions of compilers and frameworks and prune old versions.

For old versions, a failing CI could be the trigger to discuss whether to fix the build or to remove the version, but for newer versions I think someone will need to actively track and try out the releases of all these new versions (unless there you wait for build problems to be reported? After all, "guarantees" are just that: guarantees that some combinations will work, and perhaps not an exhaustive listing of all supported combinations.)

Thanks for reading it over @shimpe!

Project maintainers, including myself, will be the ones responsible for updating CI and the documentation of support. That documentation can be reviewed prior to each minor release, since it will not change during patch releases.

Typically we already get reports of build failures quite quickly on most platforms. For instance, we had issues reported about gcc 8, Boost 1.71, and Xcode 11 quite early on as they were released. But of course we can also periodically check our CI providers for new software availability. Again, immediately prior to a minor version release candidate would be an ideal time.

You bring up a good point though -- I was so focused on the "old" side of things I forgot to consider the new. Really what I am after here is a fair and documented method for phasing out support of outdated systems that we can no longer afford to support.

In any case, I think the way this should be phrased in documentation of supported platforms is "SuperCollider is tested and known to work on these platforms and software combinations."

Note - homebrew recently dropped support for macOS 10.12, which came out in Sept 2016, so I'd say 2-3 years of support on macOS is the best we can do.

updated. i am going with 2 years for all apple products and Qt, and 4 years for Windows, Linux, and non-Apple compiler toolchains.

A 4 year line seems to be still quite flexible for the systems and toolchains we would be supporting. See the notes at the end of the new document. I chose 2 years for Qt because 4 years would put us at 5.6 which we already don't support, and 3 years would put us at 5.9 which is a lot of versions in between. I'm not sure though. it looks like debian stretch only has Qt 5.7, but the Qt installer can easily give newer libraries. i would suggest saying 2 or 3 years for Qt is guaranteed but we support back to 5.7 for now.

more comments to come but that's all i have time for now.

Hey Brian, looks sensible. One question: for OSes why not major versions rather than years? That seems to me likely to be more relevant. That said I know that Mac has been doing one a year, although some of these seemed fairly minor in terms of breaking stuff. (Not like the old days, though of course YMMV).

for OSes why not major versions rather than years? That seems to me likely to be more relevant

i don't understand what you mean by "more relevant", sorry.

i don't understand what you mean by "more relevant", sorry.

Just that releases are perhaps a better measure of change than years.

As in - “for Apple, we support the current and last major OS release.” E.g. If Apple stays on OS X 10.15 for four years, we’ll keep supporting it and 10.14.

Yup.

Right now, Apple does do a OS release every year, but maybe that will change? It did for MS...

Yes, that's true. Of course the more regular releases have meant less change to some extent, so it's hard to quantify. But this at least is a crude measure of change. If there's no major release for 2 years and nothing has changed it would seem odd to just drop off the last version.

don't the same issues arise if an OS vendor speeds up their release schedule? if we're suddenly nominally dropping support for versions released just 1 year or 6 months ago that doesn't seem very good either. how about "2 years or 2 major releases, whichever is greater"?

also, i am wondering about Fedora -- I see Fedora 30 and 31 are the only 'officially supported' versions of Fedora, but fedora 30 was only released less than a year ago. @patrickdupuis any thoughts (you are the only fedora user i know)?

@dvzrv do you have any requests or points of clarification regarding these guarantees in relation to Arch packaging?

don't the same issues arise if an OS vendor speeds up their release schedule? if we're suddenly nominally dropping support for versions released just 1 year or 6 months ago that doesn't seem very good either.

Fair point.

how about "2 years or 2 major releases, whichever is greater"?

That sounds like a reasonable way to manage expectations. :-)

Given the quick release cycle and short lifetime of releases, I don't think we should make any specific support guarantees towards Fedora. Its users are far less likely to take concern with our support guarantees anyway. You might want to ask the person (Fernando?) who packages for CCRMA.

Given the quick release cycle and short lifetime of releases, I don't think we should make any specific support guarantees towards Fedora. Its users are far less likely to take concern with our support guarantees anyway. You might want to ask the person (Fernando?) who packages for CCRMA.

@patrickdupuis i just want to clarify, you're saying that we shouldn't make any effort to support Fedora at all? these guarantees will be used to decide whether to close or deprioritize tickets. i don't think we should ignore Fedora users entirely there. the bare minimum in my opinion would be to say that the latest release of SuperCollider should be compatible with and buildable on the latest release of Fedora. what do you think?

i think we will have to pay attention to how the 'patch releases keep minor release's platform support' part of this works in practice. it may not be possible to maintain that given how CI pipelines and package managers update.

updated, thanks @patrickdupuis and @muellmusik . linux support is now expressed per-distribution, and actually this year/release split was very useful to describe Qt support (2 years and 1 LTS release). nothing much changed except that now instead of supporting back to Fedora 25 it's only Fedora 31, the latest release.

Hi Brian, this looks good. One small suggestion for clarity: I think MacOS 10 is only a major release in the same sense that SuperCollider 3 is. We've had 10 for almost 20 years now. So calling 10.14 a minor release might be a bit confusing and actually doesn't fit with normal usage in the press etc. Not sure of the best rewording. You could say major release of MacOS 10? (I guess if we get 11 all bets are off anyway...)

this is a document for developers and so i think we should go by technically accurate terminology rather than what Apple or the press use. user-facing documentation will always give the explicit version numbers, as in the examples shown in this document, so there will be no room for misinterpretation.

Well, I think that's confusing the terminology with the numbering system. This is ironic since we use the same one in SC, and our 'minor' releases can have breaking changes. But okay, as long as everyone's clear.

the names major.minor.patch are more widely adopted than semantic versioning, which is the standard that imparts specific meaning to increments in version number. SuperCollider has minor releases with breaking changes, but we still call them minor releases. c.f. discussions on Wikipedia, StackExchange, StackExchange.

now that i'm at my laptop I looked at the terminology Apple uses, and I see I was wrong. 'macOS' is actually meant to refer to the series of 10.x releases, and not the Apple desktop operating system in general. I was hoping this document could outlive 10.x, but probably Apple will either never release an 11.0 or they will simply increment 10.x indefinitely like Windows appears to be doing with Windows 10. in either case this document's wording will have to be updated. I also realized you have a good point about using press/vendor terminology; since I use vendor-specific terminology for Ubuntu, Qt, and Windows ("LTS" version, "update" vs. "release") i should do the same here. i've changed it to 'major' and added explanatory notes. how's that?

Sure, I'm happy with whatever you think is best.

@brianlheim sorry I missed your reply (not keeping myself on top of things right now)

I think what I meant was, "let's not specify a number of prior versions or number of years for Fedora support". According to this (https://fedoraproject.org/wiki/Releases), Fedora puts out approx. 2 releases a year. They End-of-life their releases very quickly also (Fedora 30 is EOL May 2020, while Fedora 32 is aiming for an April 2020 release). So, our minimum support for Fedora should definitely be "latest release".

This is a great document @brianlheim. The only thing I have to suggest is, under the Platform section, we should add the names of the official distros we support next to RPI and BBB (Raspbian and Debian).

thanks @patrickdupuis @muellmusik ! updated, and also clarified that 'guaranteed support' doesn't mean we have open season to drop support on everything else. :)

i still want some time to figure out how this should be documented, ideas welcome! after that i think this should be ready for final comment period.

this RFC is now in Final Comment Period. resolution date is April 20th.

rad. thanks for this @brianlheim - I look forward to us documenting and supporting this RFC

i began work on expanding our Travis CI build matrix to cover some of these guaranteed toolchains.

platforms:

• ubuntu 16.04, 18.04
• macos 10.14 (travis does not have a 10.15 image yet)

compilers:

• xcode 10 and 11
• gcc 6 and 9 (the gcc version available on debian, and then newest version available)
• clang 4, 7, and 10 (oldest, middle, and newest version available)

additional configurations:

• gcc 9 with -DSC_QT=OFF
• gcc 9 with -DSYSTEM_BOOST=ON -DSYSTEM_YAMLCPP=ON

currently, all but the last configuration are passing. that is because the latest boost version available on Ubuntu Bionic is quite old (1.65, from 2017). does anyone know of a way to obtain a newer version? i attempted to use this PPA but it was not picked up correctly by cmake. if not, i will add a build for it on macOS instead since the latest boost version in homebrew is 1.72.

i added a 'use system libs' build for macOS and it passed on the first try. @dvzrv it's not a Linux build but would this satisfy your request that we add a CI job to exercise the "SYSTEM_BOOST" and "SYSTEM_YAMLCPP" configuration options? from my perspective this is closer to want you want, since homebrew updates quite rapidly and any issues with newer boost versions will probably be visible to us unless you find them first :)

i added builds for gcc 7, 8 and clang 5, 6, 8, and 9, which helped me catch a few more holes in certain compatibility checks. that now makes 15 total (passing!) jobs in the matrix, and overall this still runs faster than the 2 jobs on appveyor due to parallelism restrictions and caching. i don't know if we would want to keep all 15 jobs, but i found it useful to make this check at least once.

final comment period has ended, this RFC is passed :) thanks all for the productive discussion!

as detailed above i've already started implementing the CI matrix for this; i will try to make updates to documentation this week and a PR for the CI sometime soon afterward

current implementation status:

• wiki updates: https://github.com/supercollider/supercollider/wiki/Platform-Support
• release instruction updates: https://github.com/supercollider/supercollider/wiki/git-workflow-and-guidelines#releasing
• updates to website: add download page info on platform support supercollider.github.io#214
• updates to readme: readme: add platform support info supercollider#4905
• new CI jobs: add CI jobs to implement platform support RFC supercollider#4906