@joshpeterson @MichalPetryka I'd welcome your confirmation that this is the right fix.

Won't this break the package on Unity older than 2021.2? I think that 2 separate packages would be needed.

Thanks for reviewing, @MichalPetryka.
Perhaps you're right. Which versions of unity are still supported, and how popular are they?

This makes sense to me. I'm not sure how to check for the Unity version in MessagePack though. Is it possible to release two different packages?

Is it possible to release two different packages?

Yes, probably. I'm no unity expert (I don't use it myself) and the repo's primary author has been unavailable for a while. If someone else can improve on this, I'd appreciate it. Otherwise I'll get to it when I can.

Our unity build agent is failing at this point anyway, so we can't produce any unitypackage at the moment.

Perhaps you're right. Which versions of unity are still supported, and how popular are they?

Unity 2020 LTS (2020.3.x) still has support for another 6-9 months.
Unity 2021 LTS (2021.3.x) is the current active LTS release.
Unity 2022 is the actively developed version.

Should probably aim to have official support for any LTS that is still supported. Supporting the active version is definitely nice, but official support for it probably isn't required (I've seen other libraries take that approach).

Our unity build agent is failing at this point anyway, so we can't produce any unitypackage at the moment.

I'm not that familiar with how the builds are setup for this project, but one option would be to move towards Game CI. They have prebuilt GitHub actions, but could also use their docker images within Azure Pipelines.
This would also make testing on different versions easier as they publish docker images for each Unity version.

@neuecc What would you recommend? Should we abandon the PR?

I see, but is this only affecting the build machine (or local)?
If it doesn't seem to affect the packages to be distributed or the git UPM, it may be safe to merge.

If it doesn't seem to affect the packages to be distributed or the git UPM, it may be safe to merge.

It removes files from the unity package we build. This is required so that newer unity clients don't malfunction on the dll's that we ship but are also now part of their platform.

If a game developer is stuck on one unity version for years, can't they also lock down on a particular major.minor version of messagepack so that they keep working, allowing future minor releases of messagepack to evolve to work by default in newer unity clients?

If a game developer is stuck on one unity version for years, can't they also lock down on a particular major.minor version of messagepack so that they keep working, allowing future minor releases of messagepack to evolve to work by default in newer unity clients?

I mostly agree with this sentiment; however, I have experienced / can think of a couple cases where that may not hold true:

• Other technologies continue to advance and can sometimes force/strongly encourage updates.
  • Some of our developers are switching to M1 macs. .net only has native support with .net 6.x. Older MPC versions don't work correctly on .net 6.x. Hence wanting to upgrade to a newer MessagePack version.
• An established project (on an older Unity version) is looking to add MessagePack for new functionality. A developer will naturally look to start at the latest version, but will be forced to find and use an older version.

Despite those points, this is an open source project and compromises likely need to be made.

Hmmm...I see...it's a little too early to disappear completely.
How about a build of two packages like this?

[MessagePack.Unity.2.4.35.unitypackage]
[MessagePack.Unity.2.4.35.netstandard21.unitypackage]

@AArnott
Recently I was organizing packages for Unity at several libraries and changed my mind.
I think we can DROP support for 2020 in future updates (still LTS, but OK).
Minimum support version is 2021.3.
This way, only C# 9.0 and netstandard2.1 will be supported.
First of all, this PR is ACCEPT!

And the code can be nullable-enabled.
We will need to enable the warning suppression option for Unity, which I will set up if it becomes necessary.

I apologize for the delay in reporting on the policy and regarding the hesitation.

/azp run

@neuecc This PR broke the unity build in our CI because it was still building with Unity 2019. When I update it to 2021.3 in #1530, it fails with new errors that I don't know how to fix. Can you take a look?

ok, i'll check soon.

Hi, I have a problem. When i build mono standalone window i can send to socket normally, but IL2CPP didn't work!