What should be the criteria for .Net Core Merge? (Community Input)

[Balnian]

Since the PR has been open for a couple of month, i would like to know what should be the criteria to merge the PR?
https://github.com/SFML/SFML.Net/pull/143
Exemples :

• Works on Windows, Mac, Linux
• Works/tested on Windows ONLY (same as current repo?)
• Works on Windows, Linux (because we cannot test Mac?)
• ...

Please feel free to express your opinion!!!

TL;DR of PR

• Make SFML.Net work with .Net Core 2.0
• Native Windows, Linux, Mac support (.Net Core 2.0)
• Exemples in the repo using OpenTK (OpenGL in C#) are broken because OpenTK hasn't been ported to .Net Core (we might leave 1 OpenGL exemple "broken" until the OpenTK team port to .Net Core and clean up other exemples using it)
• The PR has been tested on Windows and Ubuntu 16.04 (please feel free to test other OS, distro and architecture like ARM...)

[dabbertorres]

Has also been tested on Arch Linux.

[eXpl0it3r]

I'm not enough familiar with .NET, Core, Standard to really judge this.
What is the impact on existing code bases that use SFML.NET?
What advantages does this bring to the table?
What are the downsides?

Btw. it's "example" not "exemple"

[Balnian]

The existing codebase are not directly compatible because .Net Standard 2.0 require at least .Net Framework 4.6.1 or .Net core  2.0

Advantages of using .Net Standard 2.0 is native compatibility with Windows, Linux, MacOS... (And more?). Also .Net Core is faster then .Net Framework https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/
.Net Core is also Open Source so it cannot be shutdown because a company decided to do so.

The only downside is that existing project will need to update the Framework version they target so they can use the latest SFML.Net. Also not every .Net Framework API have been ported, but i would say that only very obscur/not used a lot/windows related APIs are missing (the only one that was really missing for the SFML.Net conversion was introduced in .Net Standard 2.0 and it's a very specific API to manage memory ressources if i remember correctly)
Another "downside" is that OpenTK is not on .Net Standard yet (they are planning to in the future) it's not really a direct downside because it's not something we maintain and we still expose everything so it can work, but it will prevent interaction with OpenGL until then.

Also Microsoft is really showing that .Net Core is the new Standard for .Net, so we kind of need, in my opinion, to offer a .Net Standard library if we want to stay relevant in the future.

Finally a good place to get more info is this forum post where we discuss if we wait for .Net Standard 2.0 or not https://en.sfml-dev.org/forums/index.php?topic=22150.0
And the actual pull request https://github.com/SFML/SFML.Net/pull/143