[WIP] How do we split the QRCoder? (NuGet packages)

[codebude]

Note: This issue is part of the planning of version 2 of the QRCoder. The meta-issue can be found here. These comments have been copied into this issue here, with the comments marked as such. If comments on the topic of this issue already exist in the meta thread, they have been copied here, naming the authors.

Topic

Do we leave only the QR code generator logic in the main library (QRCoder) and make a separate package for each renderer (e.g. QRCoder.Svg, QRCoder.Png, QRCoder.Ascii, etc.)? Or do we want the generator logic + all renderers that work on all platforms without dependencies in the main package (QRcoder) and create only NuGet package per renderer with ext. dependencies? (e.g. QRCoder.SystemDrawing, QRCoder.ImageSharp, ...) Should the payload generators also be in their own NuGet package?

[codebude]

I suggest that all code that can operate with "pure .NET" code should be in the main package. This would include the generation code along with SVG, PNG and other common output formats that do not rely on external dependencies. Now that trimming is available with .NET 6+, and NativeAOT in .NET 8, splitting the project into smaller pieces just makes the project more difficult to use.

^{Originally posted by @Shane32 here.}

[codebude]

My thoughts on Question 1, how to split NuGet packages:

Original QRCoder package stays v1.x. I feel that keeping the same package name for v2 would be a landmine for folks blindly upgrading and complaining about things being broken. An updated NuGet package Readme and prominent documentation can point them to new v2.0 packages.

New Packages (v2.x):

QRCoder.Core - core QR creation logic, plus base abstraction definitions for Renderers and Payloads QRCoder.Renderers - dependency free crossplat out of the box renderers QRCoder.Renderers.System.Drawing - System.Drawing renderers QRCoder.Renderers.SkiaSharp - SkiaSharp renderers QRCoder.Renderers.ImageSharp - ImageSharp renderers QRCoder.Renderers.{other cool dependency here} - you get the picture QRCoder.Payloads - current set of payloads Renderer and Payload packages would have a dependency on abstractions defined in the Core package. The thought is that it would be pay for play. If you want to bring your own renderer to the game, you don't have to bring in anything other than the Core package as a dependency. Just supply an implementation for the abstractions defined in the Core package.

^{Originally posted by @csturm83 here.}

[codebude]

First of all let me start my saying that I think it's great to create a v2 of this really nice nuget package, and I'd be happy to help as much as I can.

Now after reading this whole thread, I would like to add my 2 cents.

I agree that having so many downloads it means we cannot just bring a bunch of breaking changes at least not to the most common ways of generating simple QR codes. Having said that, I don't think a v2 should stay in the past. I think v2 is a chance to update things, to break a few things, while keeping others the same.

As such I think @csturm83 proposal is a good idea.

I like the idea of having a Core library that has all the abstractions etc in a single package so you can build on top of the library without ever having to worry which renderer you are using.

And I like the idea of not updating the QRCoder main nuget package, as such no inconveniences can happen by a blind update.

For which .NET version to target, I think we should always target the latest version of .NET just like Microsoft does with all their nuget packages. You want to use version 8 of Entity Framework Core, you need .NET 8. I also think their nuget verisoning makes the most sense. All the package go together, like that you know that there was a change.

Finally if there's ever a need to update 1.x, not updating the base package, but instead creating new QRCoder.Core, etc... would allow for a later update to the package if a security fix or other major fix is required.

Just my 2 cents. And looking forward to contributing to the project.

PS: I think we should keep backward support as small as possible, since it's a very small set of volunteers, working on this in their spare time.

^{Originally posted by @emorell96 here.}