Aligning versioning with the minimum supported version of AutoMapper

[RubberChickenParadise]

Quite a few of the other projects that provide extensions for Microsoft.Extensions.DependencyInjection keep the version numbers the same between the main package and the extensions package.

Was there a reason for not following this convention for AutoMapper?

If not for the next release upgrading the version number to match the AutoMapper version number would make grabbing the right package easier.

[jbogard]

I was trying to follow SemVer.

On Jan 14, 2021, at 2:14 PM, Jeremy Oursler notifications@github.com wrote:

 Quite a few of the other projects that provide extensions for Microsoft.Extensions.DependencyInjection keep the version numbers the same between the main package and the extensions package.

Was there a reason for not following this convention for AutoMapper?

If not for the next release upgrading the version number to match the AutoMapper version number would make grabbing the right package easier.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[RubberChickenParadise]

@jbogard The format and incrementing of the version numbers was easy to follow, just had to dive into the dependencies on AutoMapper.Extensions.Microsoft.DependencyInjection to figure out which older version I needed to roll back to after deciding not to migrate from Automapper 8.0 at this time. (I will eventually but not when I have a deadline.) Having to use AutoMapper.Extensions.Microsoft.DependencyInjection 6.0 with AutoMapper 8.0 caused a minor slowdown.

Bumping the version number on AutoMapper.Extensions.Microsoft.DependencyInjection to match AutoMapper and keep the version numbers in sync would prevent people from having to drop into the nuget dependencies. I installed AutoMapper 10.0, use AutoMapper.Extensions.Microsoft.DependencyInjection 10.0. I install AutoMapper 10.2, use AutoMapper.Extensions.Microsoft.DependencyInjection 10.2 etc.

Really minor thing. (like how Microsoft keeps the Microsoft.Extensions space in line with major framework they were released with, makes it easy to upgrade everything at one time)

[lbargaoanu]

While I don't use the DI package, I agree that keeping the versions in sync would make things easier, semantic versioning aside :)

[kbegiedza]

+1

It's much easier to manage packages if all versions are in sync. Don't force user to check release notes/dates to manually pick compatible versions.

[lbargaoanu]

You only need to reference the DI package, so there's nothing manual, just NuGet.

[kbegiedza]

@lbargaoanu Sure, but if you have PackageA with:

• v=10.11.12
• v=9.10.11 and PackageB with:
• v=9.10.11
• v=8.9.10

You don't have any idea what kind of configuration will work - maybe v10 of PackageB isn't uploaded yet? You have to spend time checking release notes / package publish date

TBH: it's small thing.

[jbogard]

Done! With v11.0.0

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.