FastMember.Signed increases AssemblyVersion for minor updates

[danstur]

The signed package currently has an AssemblyVersion of 1.5.0. This breaks semantic versioning for people using the package: If someone requires version 1.4.0, 1.5.0 should work as a drop-in replacement. With the current configuration this requires assembly redirects which work but are annoying.

If instead the AssemblyVersion is only increased when breaking changes are introduced, we get what I would consider optimal behavior: You get a warning if you try to use incompatible versions, which you can explicitly ignore with binding redirects. For minor versions if two NuGet packages require different versions, NuGet resolves the higher version which is then installed.

Would a PR be accepted that changes this behavior to explicitly setting the AssemblyVersion in the csproj with the intent to only increasing it to 2.0.0 when/if breaking changes are ever introduced?

[mgravell]

Would a PR be accepted that changes this behavior to explicitly setting the AssemblyVersion in the csproj with the intent to only increasing it to 2.0.0 when/if breaking changes are ever introduced?

short answer: yes