Upgrade ImageSharp to 2.0.0 when it'll be released.

[a-karandashov]

ImageSharp will release a new version soon with WebP support.
It would be nice to have it in Umbraco 9 as soon as release done.
https://github.com/SixLabors/ImageSharp/milestone/8

[nul800sebastiaan]

Yes, we're constantly looking for new dependencies and update them where we can.

ImageSharp v2 will contain breaking changes and is therefore not a candidate for v9, but we'll consider it for v10.

[a-karandashov]

@nul800sebastiaan Are there any ways to use it with v9? :)
Cuz our v8 solution uses WebP and that's just one thing that's blocking us before start migration.

[nul800sebastiaan]

I haven't investigated what breaking changes there are. The best way to answer that question is to install v9, upgrade ImageSharp to the latest nightly build and try it out.

[a-karandashov]

I tried to do that, but Umbraco packages have references to ImageSharp 1.0.4, so I always see exceptions that some methods could not be found. But I'll try again later, when 2.0.0 version will be released.

[nul800sebastiaan]

That would indicate that there are breaking changes that require updates in Umbraco, so it seems the answer is: no, there is probably no way to use it with v9. :)

[ronaldbarendse]

I can confirm ImageSharp v2 won't work with Umbraco v9 because of the breaking changes it contains (or introduce to Umbraco if we'd upgraded the dependency). As Sebastiaan mentioned, we definitely want to make sure all dependencies are up to date when we release v10, so that includes ImageSharp 👍🏻

[Jeavon]

I have been testing ImageSharp v2 also, the change that breaks Umbraco is the commands parameter which has changed from IDictionary<string, string> to CommandCollection. See here. This would be easily fixed if the only breaking change that affects Umbraco but ImageSharp v2 isn't complete yet.

I would hope that when v2 is released it might be able to be included in a minor v9 version of Umbraco as WebP support is such a valuable feature, but maybe the timing will work out for v10 anyway...

I think that there are likely to be more changes required for the Blob storage provider project than Umbraco itself.

[Jeavon]

If anyone is interested I do have a branch on my fork with the changes to compile Umbraco v9 with the current ImageSharp v2 pre-release Jeavon@8742384

[arknu]

I would vote for including ImageSharp v2 in a v9 minor, if at all possible. WebP support is really a must-have that should be released as soon as possible. The changes look to be entirely internal, so there should be no external API breakage.

[skttl]

There is some public changes though. Maybe we can just have a community-driven version of v9 until v10 is ready.

Then the community can make sure to keep it updated when new versions of Umbraco gets released, and make absolutely no other changes than the changes required for ImageSharp to be v2.

[Jeavon]

@arknu that’s not the case.

[Jeavon]

If anyone wants to experiment you can get custom packages to use with 9.2 from https://github.com/Jeavon/Slimsy/tree/feature/ImageSharp2/LocalNugetPackages

[matthewcare]

Whilst we're upgrading, can we look at making it extensible?
AddImageSharp returns an IImageSharpBuilder to do many things with, but we have no access to it after the registration.
The only way I can see to add new processors, or change the configuration is to register ImageSharp myself, duplicating the Umbraco setup, which isn't very "upgrade friendly"

[ronaldbarendse]

The IImageSharpBuilder only wraps the IServiceCollection to expose a fluent API.

Instead of builder.Services.AddImageSharp().AddProcessor<MyCustomWebProcessor>(), you can directly register the processor using builder.Services.TryAddEnumerable(ServiceDescriptor.Singleton<IImageWebProcessor, MyCustomWebProcessor>()); 👍🏻

[ronaldbarendse]

Updating a dependency to a new major version would be a breaking change in itself, so Umbraco v9 will never ship with ImageSharp/ImageSharp.Web v2 by default. We don't apply upper version limits for this dependency though, so you could technically upgrade it yourself, considering the used API surface is compatible (spoiler: it isn't).

ImageSharp v2 just got released, but that isn't compatible with ImageSharp.Web v1 and as @Jeavon already mentioned, that in turn will also contain breaking changes that aren't compatible with Umbraco v9.

[p-m-j]

we're discussing this internally but it's worth mentioning here also for clarity/visibility

What should I do if I update my own dependencies without changing the public API?
That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api

[markadrake]

Are these breaking changes to (a) Umbraco, or (b) to the software and solutions people have built and distributed with Umbraco?

I ask because if it's (a) then I think there is a need for more tests to be written. All tests pass when I upgrade ImageSharp.Web to the latest alpha version (2.0-etc). I wouldn't mind jumping in and trying to write some new tests to add to cover what's missing. It would give me an excuse to try and write some missing tests and learn something in the process.

If it's (b) I can't help but complain a little bit. I don't know if the basis of my complaint comes from my own incompetency with C#, or software design, or internal politics – but here's what I have learned:

I'm sure everyone knows this....

• There's a static method AddUmbracoImageSharp, in a static class UmbracoBuilderExtensions.
• I can't override static methods, like in any way, shape, or form. It seems impossible...
• So I go to where it's being called in AddWebComponents and go to where that's being called in AddBackOffice and... it's static on static on static.

What is "developer friendly" about this design?

Pending my gross incompetence and missing something core to Umbraco that is broken from using ImageSharp.Web v2.0... Is this not a potential solution?

1. Move the AddUmbracoImageSharp method to somewhere a developer can override it.
2. A package developer can then add ImageSharp.Web v2.0 as a dependency, and
3. Override AddUmbracoImageSharp,
4. Override or bring their own implementation of CropWebProcessor (?),
5. And people can make the conscious decision whether to use 1.0 or upgrade to 2.0?

I don't write a lot of C# sorry for the technical inaccuracies, over simplification, and junior recommendations.

[p-m-j]

If we can support imagesharp 2.0 without altering any of our public interfaces and without removing any public methods we should be fine to make the changes in a minor version.

The main issue seems to be the dict -> command collection change, is it possible for us to hide that change from downstream users by trasnslating the dict to a command collection?

Tests don't cover whether there is an backwards incompatible change to an API (e.g. if I add a method to a public interface that may not break any tests but it is a backwards incompatible change) there are some tools that can help e.g. https://blog.ndepend.com/find-api-breaking-changes-in-your-net-libraries-and-frameworks/

[skttl]

@p-m-j would this be good enough? #11991

[p-m-j]

I don't see any backwards incompatible changes... however there is some unfortunate news,

Our existing package references (web.common and infra) for ImageSharp do not have a value set for PrivateAssets, so we have made it trivially easy for folks to make use of classes in the ImageSharp namespaces without taking a direct dependency on the project.

This means the following sentence from the Semver FAQ doesn't hold true.

Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts.

I don't think there's going to be rapid movement on this topic, but thanks so much for the PR and 🤞

[arknu]

@nul800sebastiaan ImageSharp.Web 2.0.0 was just released. I don't see upgrading to ImageSharp v2 on the Umbraco 10 release page. Should I file a new bug? (might have a go at doing it myself - I'm really keen to see this in v10, as it enables support for WebP).

[nul800sebastiaan]

Yeah not to worry it's on our todo list for v10. 😄

[ronaldbarendse]

The work required to upgrade to v2 has already started a month ago and is now almost complete: #12185 👍🏻

[markadrake]

Happy to comment here that Umbraco 10 and v2 are working great together. Thanks for all the effort put into the upgrade.