Vega-strike-engine-source: Decision on compiler/platform support

[BenjamenMeyer]

Several questions raised in https://github.com/vegastrike/Vega-Strike-Engine-Source/pull/33#issuecomment-609089044:

I'm a cutting edge kind of guy, and it got me into trouble before. I vote we ditch older environments for building but not for playing. We require new if not newest compilers so we can clean the code as much as possible but release new version binaries for older systems as well. We're an open source project, it should be fun to contribute. No one likes to maintain legacy code. If we wanted to do that, we'd spend another hour at our day job. As an aside, the code is filled with ifdefs for MS Visual C 6 (circa mid-90's!) and Solaris. I think we can drop support for these.

1. What compilers do we want to support?
2. [x] gcc
3. [x] clang
4. [x] ~VC6~ (dropped per https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/40#issuecomment-625288625)

5. [x] ~VC2020~ VS2017

6. What legacy platforms do we want to support?

7. [x] ~Ubuntu 14.04~ (dropped per https://github.com/vegastrike/Vega-Strike-Engine-Source/issues/40#issuecomment-623743970)
8. [x] Ubuntu 16.04

9. [x] Ubuntu 18.04 (current LTS for Ubuntu until 20.04 is released in April 2020)

10. How long should a platform be supported?

[Loki1950]

First we have to get Windows build at all which will be not fun and where is the Mac OSX version yeah we did support that as well

[BenjamenMeyer]

Windows support for Travis-CI is still experimental; according to the documentation they're currently working on VS2017 support. Propose we move to VS2017 as the official compiler until that matures.

NOTE: Even once the gate is in place it'll still be allowed to fail for a while as we figure it out and as Travis-CI matures it's Windows target support.

[Loki1950]

Good reasoning @BenjamenMeyer IIRC VS2017 is supported by M$'s community version of VS

[BenjamenMeyer]

@Loki1950 updated the description per VS 2017.

[nabaco]

I suggest that for compiling, we support officially maintained distro's and officially maintained compilers.

So for Ubuntu, 14.04, 16.04, 18.04 with the GCC/Clang version that is supplied with them.
Once 14.04's support is fully dropped, we can drop the support for compilation on it too.
I guess the same would be for Windows+MSVC (Win10 only) and Xcode on MacOS (IDK what's the versioning there).

The harder issue, as per @royfalk's comment in #33, is how to make sure the compiled binaries run on older platforms? How far do we want to go with it?
Though on Windows it might not be such an issue, but on Linux/Mac it can become a real challenge. Unfortunately, open source libraries don't have a good track history for backward compatibility 😞

If we want to maintain playability on older platforms, we might want to integrate tests for that (in Travis CI we can use Dockers for that). But again, how far do we want to go? Ubuntu 12.04? 6.04?
My suggestion would be to assume that video gamers run quite modern platforms (newer hardware, driver support, etc.). Based on that assumption, with each release, we can write what are the oldest supported/known to work platforms (AKA minimum system requirements), and not look back anymore. I think that would be easiest for both Devs and Users.

[stephengtuggy]

@nabaco Sounds good to me. On that same line, I think we could include Ubuntu 19.10 as well. Possibly LLVM (do I have that right?) And maybe at some point, we can try to get the code working on Debian 10 (Buster), as well.

[stephengtuggy]

I will further add that when an operating system or version is no longer supported, that almost immediately brings serious security vulnerabilities. So from a DevSecOps perspective, we will probably want to stay away from older platforms that aren't alive anymore. ;-) But hopefully continue to support hardware that's decently current (within the last 5 years?) on an ongoing, rolling basis.

[nabaco]

@stephengtuggy just a comment, AFAIK, LLVM==clang

[BenjamenMeyer]

@stephengtuggy I suggest for Ubuntu we stick to LTS versions as official supported, may be running the lastest 6 month (which 19.10 would fall into, but it'll quickly fall off).

I'm open to adding anything, but one step at a time. Let's get Ubuntu down first then we can add Debian - an easy jump.

[BenjamenMeyer]

For each platform, we use the default compiler versions for that platform where available.
So for Ubuntu 20.04 we use the default GCC and CLang compilers.
Similar for Mac OS X since the XCode Suite is tied to the releases.
For Windows we define a default since there isn't one natively provided.

[stephengtuggy]

@nabaco You're right. Gah, I was forgetting the details on that. Thanks.

[stephengtuggy]

@BenjamenMeyer Sounds good to me.

On Windows specifically, Visual Studio (2017?) could probably be considered the default. Other than that, everything looks good! :+1:

[ermo]

What is the use case for supporting Ubuntu 14.04 LTS?

According to https://ubuntu.com/about/release-cycle 14.04 LTS is in Extended Security Maintenance mode.

FWIW, 14.04 LTS is no longer listed on https://packages.ubuntu.com.

Rarely has "It's dead Jim" rung so true IMHO, _particularly_ if it's blocking the removal of the external boost library as discussed in #38.

[BenjamenMeyer]

The primary case, IMHO, is just that it was in the existing support set; and was working.
The question is when do we want to drop it?

1. Do we want to include it in the 0.6.x release and drop in the 0.7.x release?
2. Do we just want to go ahead and drop it?

We probably need to come up with a proper Platform Support & Drop policy to help with this in the future.

[stephengtuggy]

I would think we could just go ahead and drop 14.04 LTS right away. Unless we need it to compare the functionality of the old vs. the new code, on the same platform (apples to apples).

Thoughts?

[nabaco]

I agree on that. We can say that 0.5.3 is supported on 14.04 LTS, and all future releases don't.

[nabaco]

BTW, we are talking here compilation only. A .deb package should run on it IMO.

[nabaco]

Vote

Drop Ubuntu 14.04 LTS compilation support

Using the smiley button on the top right:

• 👍 - for
• 👎 - against

[Loki1950]

Dropping Ubuntu 14.04 just seem a bo brainer

[nabaco]

@danielrh @stephengtuggy @ermo @pyramid3d @pheonixstorm @royfalk @bottledbyte @bmorel

Feel free to make a vote if you wish :)

[nabaco]

As we have an unanimous agreement on this (7 - for, 0 - against), I'm merging the PR. Thank you all for voting.

[BenjamenMeyer]

I think we can drop VS 6 too; we're having enough issues getting current Windows build and nothing should be support VS6 any more any how.

[nabaco]

I think we can close this issue then :)

[nabaco]

Regarding supporting platforms that are not native to Travis-CI, I think we should open a separate issue, as it'll involve Dockers

[BenjamenMeyer]

Before we close this, let's get something in the Git Hub wiki to reflect this.

[royfalk]

Just so we’re clear, VS6 is ancient.
It was released in 1998!
So all those ifdefs, they can go.

From: Benjamen Meyer [e-mail]
Reply-To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Date: Thursday, 7 May 2020 at 18:30
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail], Mention [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Decision on compiler/platform support (#40)

Before we close this, let's get something in the Git Hub wiki to reflect this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/40#issuecomment-625326298, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEHXSFK253IA2CN7PX3RQLHX5ANCNFSM4L7GGTVQ.

[BenjamenMeyer]

@royfalk yes, we start cleaning up any ifdefs specific to VS6 (but don't apply to other VS compilers) as part of the 0.7.x work.

[BenjamenMeyer]

@royfalk filed #93 to track that separately from this

[BenjamenMeyer]

With respect to support cycles:

• Ubuntu (https://wiki.ubuntu.com/Releases) - Standard Support
• Microsoft Windows (https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet) - what's currently under normal support for the average user
• Red Hat/CentOS/Fedora (https://access.redhat.com/support/policy/updates/errata, https://wiki.centos.org/About/Product, https://fedoraproject.org/wiki/End_of_life) - Standard Support cycles

where possible let's only track LTS releases.

[BenjamenMeyer]

For mac: Proposing Current + last 4 releases.
Honestly, we're tied closely to what homebrew supports as we use that for dependencies on Mac OSX. So we'll have to tie that in somehow too

[stephengtuggy]

For Mac, I would propose current + last 2 releases.

[nabaco]

Recorded the policy
https://github.com/vegastrike/Vega-Strike-Engine-Source/wiki/Platform-Support

[BenjamenMeyer]

@nabaco thanks; I updated it with a more extensive policy. Please review for grammar/spelling/tack/etc.

[ermo]

The following captures some points discussed on gitter last night with some additions by yours truly (chiefly chocolatey support on Windows):

• Linux: Only support building on actively supported desktop Linux distributions
  
  
  
  • For the time being, focus on Debian/Ubuntu
  
  
  • Packagers on other distributions are welcome to package VS for their preferred platform and contribute build instructions to the VS documentation
  
  
• macOS: Only support building on macOS versions supported by Homebrew (generally the 3 latest releases, but let Homebrew worry about that)
  
  
  
  • Distributing VS and its data-sets via Homebrew is the obvious way forward unless we want to be in the Apple Store
  
  
• Windows: Only support building on Windows releases that are officially supported by Microsoft
  
  
  
  • Windows 7 is no longer supported by Microsoft
  
  
  • Windows 8.1 is in the Extended Support period as of writing this
  
  
  • Consider whether it makes more sense to maintain builds for the open-source chocolatey (which is to Windows what Homebrew is to macOS)
  
  

[nabaco]

@ermo I agree with everything you wrote, including using chocolatey for windows.
Thank's for that good summary :+1:

[nabaco]

@nabaco thanks; I updated it with a more extensive policy. Please review for grammar/spelling/tack/etc.

@BenjamenMeyer I have went over your changes, look very good, great job! I don't think I have something to add to such a detailed policy 😄
I'll try to go over compiler versions and add them to the page, once I have a moment for that.

[BenjamenMeyer]

@nabaco I took compiler versions for GCC from the supported Ubuntu platforms (packages.ubuntu.com). Don't know how Fedora, Mac will change them.

[BenjamenMeyer]

Remaining issues to close this:

• [ ] Supported Clang Compiler Versions (CLang in general)
• [ ] Supported XCode/Clang Compiler Versions (Mac OS X)
• [ ] Open an issue for each platform that is listed as In-Progress
• [ ] Open an issue for each platform that is not under CI yet

That doesn't mean they're fully in CI, working - just that it's documented as our targets.

[BenjamenMeyer]

Some things we need to consider in this is also our dependencies and tool chain.
The below outlines the CMake versions on various platforms. Base on it, I suggest we support CentOS 8 and Debian 9 (Stretch) and later as older versions will hold us back the most for CMake functionality.

Mac:

• Home Brew: 3.18

Windows

• Chocolatey: 3.18

Ubuntu

• 16.04 (xenial): CMake 3.5
• 18.04 (bionic): CMake 3.10
• 20.04 (focal): CMake 3.16

Debian

• 8 (Jessie): 3.0
• 9 (Stretch): 3.7
• 10 (Buster): 3.13

CentOS/Red Hat (RH by proxy):

• 6: 2.8.12
• 7: 2.8.12
• 8: 3.11

Fedora:

• 32: 3.17
• RawHide: 3.18

SuSE:

• Leap 15: 3.10
• Leap 15.2: 3.17
• Tumbleweed: 3.18

[stephengtuggy]

Boost versions on various platforms:

Mac:

• Homebrew: 1.73

Windows:

• Chocolatey: 1.67.0 (for Visual Studio 2015)

Ubuntu:

• 16.04 (xenial): 1.58.0
• 18.04 (bionic): 1.65.1
• 20.04 (focal): 1.71.0

Debian:

• 8 (jessie): 1.55.0
• 9 (stretch): 1.62.0
• 10 (buster): 1.67.0

CentOS/RedHat:

• 6: 1.41.0
• 7: 1.53.0
• 8: 1.66.0

Fedora:

• 30: 1.69.0
• 31: 1.69.0
• 32: 1.69.0
• RawHide: 1.73.0

SuSE:

• Leap 15: 1.66.0
• Leap 15.2: 1.66.0
• Tumbleweed: 1.71.0

[stephengtuggy]

I would dearly love to drop support for Boost versions older than 1.67, but it doesn't look like that's feasible yet. At least, not unless we start including Boost again ourselves.

[stephengtuggy]

Note that Debian 9 stretch and before have reached their End of Life: https://wiki.debian.org/DebianReleases . So we can probably drop support for them.

[stephengtuggy]

Clang versions on each platform:

Mac:

• Clang based on LLVM 8.0.0 or later bundled with Xcode 11.0 and later, apparently -- https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_11.x_(since_Free_On-Device_Development)

Windows:

• Clang 8.0.0 or later bundled with Visual Studio 2019 and automatically kept up to date -- https://docs.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=vs-2019
• LLVM 10.0.0 available on Chocolatey

Ubuntu:

• 16.04 (xenial): 3.8
• 18.04 (bionic): 6.0
• 20.04 (focal): 10.0

Debian:

• 8 (jessie): 3.5
• 9 (stretch): 3.8
• 10 (buster): 7.0

CentOS/RedHat:

• 8: 8.0

Fedora:

• 30: 8.0
• 31: 9.0
• 32: 10.0
• RawHide: 10.0

SuSE:

• Leap 15: 5.0
• Leap 15.2: 9.0
• Tumbleweed: 10.0

Note that all of these versions support the C++14 standard -- https://en.cppreference.com/w/Template:cpp/compiler_support/14

It looks to me like we can say that we support clang versions 3.8 and above. And we might be able to switch to C++14 as our language standard, if the various GCC versions are also compatible. I know Visual Studio 2017 and up is.

[stephengtuggy]

It doesn't look like clang is necessarily available on CentOS/RedHat versions prior to 8.

[stephengtuggy]

gcc versions on various platforms:

Mac:

• On Homebrew: gcc 10

Windows:

• On Chocolatey: MinGW-w64 8.1.0

Ubuntu:

• 16.04 (xenial): gcc 5.3.1
• 18.04 (bionic): gcc 7.4.0
• 20.04 (focal): gcc 9.3.0

Debian:

• 8 (jessie): gcc 4.9.2
• 9 (stretch): gcc 6.3.0
• 10 (buster): gcc 8.3.0

CentOS/RedHat:

• 6: gcc 4.4.7
• 7: gcc 4.8.5
• 8: gcc 8.3.1

Fedora:

• 30: gcc 9.3.1
• 31: gcc 9.3.1
• 32: gcc 10.2.1
• RawHide: gcc 10.2.1

SuSE:

• Leap 15: gcc 7
• Leap 15.2: gcc 7
• Tumbleweed: gcc 10

If we decide not to support CentOS/RedHat versions prior to 8, or Debian versions prior to 9 (stretch), then every other C++ compiler we would support is compatible with C++14 or higher.

[stephengtuggy]

If we decide not to support CentOS/RedHat versions prior to 8, or Debian versions prior to 9 (stretch), ....

@BenjamenMeyer have we already made a decision regarding the above?

[BenjamenMeyer]

For the moment I'd prefer to keep support options for CentOS 7 (starts EOL later this year; fully EOL in 2024 - https://wiki.centos.org/About/Product). Debian 8 is completely EOL now so we can drop that.

[BenjamenMeyer]

Rule of Thumb: if a distro is in question, check it's support schedule. If it's in maintenance like CentOS7 goes into starting in 2021 then we can use market share as a secondary factor - e.g if a lot of people are still using it for desktop then let's try to maintain support; if it looks like folks have moved on then drop it at that point.

[stephengtuggy]

So you want to go ahead and support CentOS 7 for now, even though it has a pre-3.0 version of CMake?

[BenjamenMeyer]

@stephengtuggy have to been supporting it?

Tldr; don't break it if we already support it, but don't go out of your way to if we haven't been given the EOL date.

I'm sure there's access to CMake 3 via an SCL pack of someone's really wanted it on CentOS 7. And it's probably reasonable to ask them to use that given the EOL date and the effort on our part. So I wouldn't go out of my way to support them, but wouldn't to break them either.

[stephengtuggy]

@BenjamenMeyer A couple of PRs back, I changed the minimum CMake version listed in CMakeLists.txt from 2.8.8 to 3.5. That's the extent of the breaking changes I've made so far. It should be easy enough to change that back.

[stephengtuggy]

But I probably won't bother to put in RPM dependencies specifically for RHEL/CentOS 7, because that would be a lot of extra work.

[BenjamenMeyer]

@stephengtuggy don't worry about changing it back. SCL 7 has CMake 3.6 (https://centos.pkgs.org/7/centos-sclo-rh-x86_64/llvm-toolset-7-cmake-3.6.2-9.el7.x86_64.rpm.html); it should be reasonable to use that for the last few months of support for Cent7/RH7.

[stephengtuggy]

@BenjamenMeyer OK.

[ermo]

@stephengtuggy & @BenjamenMeyer

Can I just take a moment to let you know that I'm grateful for the donkeywork you've been doing in mapping out the various supported lib and compiler versions across distros?

Mad props!

[nabaco]

@BenjamenMeyer I think we should maintain a table somewhere with all of the data. The systems we support, the harder it is to follow all the dependencies.

[nabaco]

Furthermore, as a team, I think we should decide upon a process to revisit this every once in a while to make sure things are still relevant.
Once a month? Every 3 month? what do you say?

[BenjamenMeyer]

given our speed, probably every 6 months for the moment; we can revisit faster if we find that's too infrequent.

[stephengtuggy]

Remaining issues to close this:

• [ ] Supported Clang Compiler Versions (CLang in general)

I suggest that we support CLang v4 and up, since 3.x doesn't seem to be fully c++11 compliant. Esp. with regard to templated functions/methods.

• [ ] Supported XCode/Clang Compiler Versions (Mac OS X)

I suggest XCode 11 and up.

• [ ] Open an issue for each platform that is listed as In-Progress

See #292 , #293

• [ ] Open an issue for each platform that is not under CI yet

See #294

That doesn't mean they're fully in CI, working - just that it's documented as our targets.

I'm hoping that we can finish this list and close out this ticket within the next couple of days.

[BenjamenMeyer]

@stephengtuggy per CLang & XCode, check the against our supported platforms. I think we selected XCode 11 as it had support across the different active versions of Mac OS. Clang 3 is similar.

Also, I expect this will be a regularly reviewed item to ensure that (a) we add new versions of various platforms and (b) drop older ones that have left their support cycle.

There's not really any good mechanism in GH Issues for having a recurring item like that unfortunately. Perhaps I can add a board for those kinds of things...they'll be few and far between, but that'd at least give us visibility for anything we want periodically reviewed.

[BenjamenMeyer]

NOTE: We need to make sure to keep https://github.com/vegastrike/Vega-Strike-Engine-Source/wiki/Platform-Support up-to-date with this issue.

[BenjamenMeyer]

Updated the Platforms Support Wiki page:

• Dropped Fedora 31
• Added OpenSuSe Leap
• Added Debian LTS (Stretch) and Current (Buster)