Merging ImageSharp.Drawing into the ImageSharp Repository for v4: Simplifying Development and Enhancing Focus

[JimBobSquarePants]

What is happening?

We are merging the ImageSharp.Drawing repository into the main ImageSharp repository as part of the upcoming v4 release cycle. This change is intended to simplify development and streamline the management of the libraries.

Why are we merging the repositories?

When we initially split the ImageSharp and ImageSharp.Drawing repositories, it was to allow each library to evolve independently. At the time, ImageSharp.Drawing was not ready for a full release in step with ImageSharp. This separation gave us the flexibility to iterate and stabilize both projects at their own pace.

Now, both libraries have reached a level of maturity and stability that makes maintaining separate repositories unnecessary. By merging the repositories, we aim to:

1. Simplify Release Management: Managing separate repositories has introduced unnecessary complexity to our release process. A unified repository will make it easier to release both libraries together without coordination overhead.

2. Streamline Issue Management: A single repository simplifies issue and discussion tracking. Whether it’s a bug report or feature request (excluding font-specific issues, which will remain separate), having a central location for these discussions will reduce friction.

3. Focus Development Efforts: Maintaining separate repositories has led to the Drawing library being somewhat neglected. Merging allows us to consolidate effort and focus on areas like improving rasterization performance.

What does this mean for packages?

As part of this merge, the libraries will be consolidated into a single package. This unified package simplifies dependency management and ensures all capabilities are readily available without additional integration steps. Integrating ImageSharp.Drawing directly into the core ImageSharp package eliminates confusion around version compatibility and provides a consistent experience for users.

Next Steps

As we work through this transition, we will:

• Provide updates on the timeline and progress of the repository merge.
• Maintain quality and stability for the consolidated package.
• Invite feedback on the changes and their impact.

This change is intended to make development and usage of ImageSharp more efficient and focused. If you have any thoughts or concerns, feel free to share them in the usual channels.

[antonfirsov]

What happens to SixLabors.Fonts? It would feel weird to me to have such a package dependency in the majority of apps that do not deal with drawing at all.

[JimBobSquarePants]

Can you point out where that magic happens? How for example would we bump the version number for ImageSharp.Drawing without bumping ImageSharp when no changes have taken place there.

Also…

Merging both repos is ok. But the step to merge into one project. I dunno. I find it good to still have two separate Nuget packages.

I don’t see much point merging the repos without merging the packages. I wanted a single project so I could improve things incrementally without additional overhead. I also want to support additional format decoders for metafiles and have them in the default configuration.

[stefannikolei]

At the end they are just ProjectReferences. See https://github.com/DuendeSoftware/products/blob/main/identity-server/src/EntityFramework.Storage/Duende.IdentityServer.EntityFramework.Storage.csproj

And here is the build:
https://github.com/DuendeSoftware/products/blob/main/identity-server/build/Program.cs
So it seems that they just call dotnet pack

[JimBobSquarePants]

Reading the repository configuration that appears to mean a version number bump for all packages regardless of changes.

[stefannikolei]

Exact.

[antonfirsov]

Managing separate version numbers might be difficult since we use the commit height to do so.

I'm not suggesting to manage separate version numbers, just to keep the packages separate. If it's not difficult to do, IMO there is user value for keeping them separate.

I also want to support additional format decoders for metafiles and have them in the default configuration.

Those formats may contain vectorgraphic components, which IMO makes them unfit to be directly decoded into an Image. I rather view them (together with SVG) as objects that can be rendered on an Image or a future Canvas object.

[tocsoft]

I would suggest 1 repo, 2 projects IS & IS.Drawing but I would keep both projects in sync with each other at the version number level (no different to it being a single package then) but split for convenience etc

[antonfirsov]

no different to it being a single package then

The difference is in the dependecny graph. Currently ImageSharp.Web or other 3p projects doing web resizing do not depend on SixLabors.Fonts. If we merge the packages, they will take a dependency, which will be a dummy in the vast majority of the cases.

[tocsoft]

agreed, i was referring to the version number only in my statement, but I agree your statement is correct

[JimBobSquarePants]

I do have one last argument for merging the code base. I would love to make some major breaking changes by ditching the fluent extensions and introducing a canvas type. Something like Graphics or SkCanvas where people could bring their own.

My dream would be to one day be able to have multiple canvas types. CPU, GPU, SVG

I don’t think I can justify such sweeping changes without retiring the separate project.

[stefannikolei]

I would suggest the following:

• For the beginning stick with separate projects in one repository. I assume that SixLabors.ImageSharp.Web will also get merged into the same repo?
• When it really becomes necessary the 2 projects can still be merged for the next major version.