I know this has been brought up before. But, Umbraco really needs to update dependent NuGet packages more often, even if doing that means a small breaking change.
My particular pet peeve is AutoMapper. Umbraco is hardwired to version 3.3.1, which is positively ancient (newest is 5.2). Version 3.3.1 has some bugs which are fixed in 4.0 - but I can't use the fixed version in my own code because of Umbraco.
Backwards compatibility is good, but backwards compatibility at all costs is not. Just look at what that did to Windows.
If needed, call v7.6 v8 and v8 v9, but please do something, as the current v8 is still a long time out.
I think the current strategy with dependencies needs to be rethought. Either the major versions needs to be increased more frequently to allow for such updates, or the policy of absolute backwards compatibility needs to go. With the increasing use of NuGet, you get problems when Umbraco is locked to a very old version of a popular library like AutoMapper. I might want to install another package that depends on a newer version, but that can't be done.
There are of course ways around that, but you shouldn't have to jump through all kinds of hoops for this.
I remapped automapper namespaces and changed the eway sdk to use said new namespaces because it was incompatible.
I could possibly do something similar for Umbraco, that way it thinks of Automapper as a different object, and you can use the two different versions together.
Thanks, that is certainly a solution, although not a pretty one.
I ended up going a different route - since you can change which mappers AutoMapper uses (and my bug was in a specific mapper), I just backported the fixed version and configured AutoMapper to use that instead.
My point with this thread was more to raise the topic of whether absolute backwards compatibility is such a good idea. Having your dependencies frozen for 3+ years is too long in my opinion.
I agree, but IMO I think we should avoid using anything like automapper.
I took a look in the eWay code and the amount of rubbish they had to put in to use automapper and it was about the same as if they had just written the conversions into the objects themselves (in couple of instances it was actually more lines of code to use automapper).
I guess it would be good for quick lazy prototyping complex conversions, but I think for me that would be all I would ever use it for.
If Umbraco wish to use these sorts of common, quickly updated, packages extensively and still provide backward compatibility; Then maybe use the method I used for eWay on Umbraco. Change the namespace of the package you are using (most are git projects) and let the community know that if they wish to use an inbuilt library, eg: AutoMapper, then they have to use the namespace U_AutoMapper instead of the normal one.
Upgrade AutoMapper
I know this has been brought up before. But, Umbraco really needs to update dependent NuGet packages more often, even if doing that means a small breaking change.
My particular pet peeve is AutoMapper. Umbraco is hardwired to version 3.3.1, which is positively ancient (newest is 5.2). Version 3.3.1 has some bugs which are fixed in 4.0 - but I can't use the fixed version in my own code because of Umbraco.
Backwards compatibility is good, but backwards compatibility at all costs is not. Just look at what that did to Windows.
If needed, call v7.6 v8 and v8 v9, but please do something, as the current v8 is still a long time out.
I presume you've read this thread?
https://our.umbraco.org/forum/umbraco-7/developing-umbraco-7-packages/74650-why-not-upgrade-from-automapper-to-331-or-latest-version-of-automapper
Yes, I read that.
I think the current strategy with dependencies needs to be rethought. Either the major versions needs to be increased more frequently to allow for such updates, or the policy of absolute backwards compatibility needs to go. With the increasing use of NuGet, you get problems when Umbraco is locked to a very old version of a popular library like AutoMapper. I might want to install another package that depends on a newer version, but that can't be done.
There are of course ways around that, but you shouldn't have to jump through all kinds of hoops for this.
I remapped automapper namespaces and changed the eway sdk to use said new namespaces because it was incompatible.
I could possibly do something similar for Umbraco, that way it thinks of Automapper as a different object, and you can use the two different versions together.
You can see it here
Regards,
Damien
Thanks, that is certainly a solution, although not a pretty one.
I ended up going a different route - since you can change which mappers AutoMapper uses (and my bug was in a specific mapper), I just backported the fixed version and configured AutoMapper to use that instead.
My point with this thread was more to raise the topic of whether absolute backwards compatibility is such a good idea. Having your dependencies frozen for 3+ years is too long in my opinion.
I agree, but IMO I think we should avoid using anything like automapper.
I took a look in the eWay code and the amount of rubbish they had to put in to use automapper and it was about the same as if they had just written the conversions into the objects themselves (in couple of instances it was actually more lines of code to use automapper).
I guess it would be good for quick lazy prototyping complex conversions, but I think for me that would be all I would ever use it for.
If Umbraco wish to use these sorts of common, quickly updated, packages extensively and still provide backward compatibility; Then maybe use the method I used for eWay on Umbraco. Change the namespace of the package you are using (most are git projects) and let the community know that if they wish to use an inbuilt library, eg: AutoMapper, then they have to use the namespace U_AutoMapper instead of the normal one.
is working on a reply...