We have moved to GitHub Issues
Created by Shannon Deminick 05 Aug 2015, 11:36:23 Updated by Shannon Deminick 13 Sep 2018, 04:23:18
Relates to: U4-6957
Relates to: U4-8227
Subtask of: U4-7594
There's a new new version
Couldn't this be done the same way log4net was updated in 7.6? This old buggy version of AutoMapper is causing us lots of issues in custom code. I'm aware that AutoMapper 5.x and 6.x have some API changes, but then at least please use AutoMapper 4.x instead. 3.x is really horribly buggy in some use cases. Having to wait for v8 is really quite painful.
I'm interested to know what bugs are you referring to that are so horrible?
An update to 4.x may be feasible but i know the API changes to 5/6 will break a lot of implementations (including ours) so we cannot go there until v8
@Shandem In particular, we are doing a lot of mapping of expressions. This is so buggy in 3.x that I had to backport the expression mapper from 4.x - but there is only so much you can fix by backporting. In particular, backporting anything from 5.x or newer is difficult due to the API changes. And there are of course fixes outside the mapper itself that can't be backported.
Also, when using NuGet it becomes problematic when Umbraco is locked to a version released in January 2015. Other packages have updated dependencies long ago, starting a chain reaction of not being able to update.
Not particularly causing an issue but trying to integrate a 3rd party SDK that uses a later version of AutoMapper is an issue.
Is it still the case that this won't be updated/removed until v8?
The latest 7.x is on the latest AutoMapper that we can be on without breaking changes introduced by AutoMapper... so yes, we cannot upgrade further than where we are at in the 7.x series.
@Shandem Frankly, I'd rather see some minor breakage in a 7.x release than the current situation where we are stuck with ancient libraries with loads of bugs. Backwards compatibility is good, but this is too much of a good thing.
Also, while v8 will be released with up-to-date libraries, the same thing is just going to happen again, unless you change this policy of absolute backwards compatibility.
I understand the frustration. The main issue is the prolonged major version of v7 and we hope to not have that same issue into the future.
I haven't tested this for quite some time so I'm unsure exactly what breaks moving past our current AutoMapper version in 7.x to something higher. AFAIK there was some larger changes required in v8 for us to move to the latest versions so i don't think the AutoMapper changes are insignificant.
Backwards Compatible: False
Due in version: 8.0.0