hadashiA
commented
3 months ago Thanks for the question. I will try to explain.
Reasons for moving to NuGet
- MemoryPack was written using C# 11 and later features, but a downgraded version was needed to distribute the source code to Unity. This seemed to complicate maintenance a bit.
- In the previous version, the source code was committed twice, once for Unity and once for dotnet. These synchronization errors have also occurred.
- Previous versions had API differences between MemoryPack built for Unity and MemoryPack from NuGet.
- MemoryPack depends on System.Runtime.CompilerServices.dll. For users, it was inconvenient to import this and resolve conflicts.
- In recent years, the NuGet libraries have been made AOT-safe by Source Generator. The possibility of using NuGet libraries from Unity is expanding.
Reasons for the increased Unity support version
- MemoryPack includes a SourceGenerator. For this to work with older Unity, the source generator for the Roslyn3 series and the code to be generated must work with C# 9. If this can be stopped, it will be easier to operate.
- NuGetForUnity did not have the ability to distribute multiple versions of SourceGenerator.
- We hope this issue will be resolved here: https://github.com/GlitchEnzo/NuGetForUnity/pull/616.
- MemoryPack is also a progressive library with its own binary usage. We are also hopeful that most users will take advantage of the new Unity, as most probably are not conservative.
These are my views included. However, Cysharp is taking a similar direction for dotnet and Unity combined libraries such as R3 , ZLogger, etc.
Shaun-Fong
Hi!
Any reason why you are changing the working distribution workflow to Nuget and dropping support for older Unity? Thanks to tags, most users can definitely stay on 1.10 if needed, but I'm curious why you decided to change that.