[WIP/QRCoder2] How do we split the QRCoder? (Github repositories)

[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

In dependency to #540 , the question arises as to how we split the source code. Do we leave all sub-projects (=NuGet packages) in the main repository (codebude/QRCoder) and thus avoid duplication of test- and demo projects and have issues centrally or do we create one repository per NuGet package? If the latter, where do we collect the issues?

[codebude]

I think these questions 2 and 3 are the same. If all NuGet packages are released together, having a single repository makes testing and publishing much easier. Most specifically if they are separate, then it's a real pain to utilize unreleased features in dependent repositories. Rather, you have to release the parent package, then test and update the dependent packages, then release them, hoping that you didn't miss something and have to go back and change the parent package. Having a single repository ensures that all tests are run on the same unified version of QRCoder.

As for versioning, I think we can learn from MS's example, where with .NET Core 3.x and prior, each package had unique versioning, and with .NET 5+ every package has the same version number. Having the same version number for all related packages makes it very easy for a developer to identify which version is the latest, and which version was tested with what dependency.

As a practical example why this is useful, if you pull a 'child' package, say QRCoder.SkiaSharp, and then an update is pushed for the base QRCoder library, developers will see an update to QRCoder.SkiaSharp and pull it, whereas if each package had individual versioning, they would not know that QRCoder had an update without specifically checking. And then to pull it now they would have two references in their project file.

This issue occurs today with ASP.NET Core 2.1 applications running on .NET Framework 4.8 (a still-supported scenario), where all user-referenced dependencies are up-to-date, but yet some of the indirectly referenced dependencies are out of date, and worse, have a security-related flaw. This rarely happens with .NET 5+ where most packages are released together, each version referencing the same version of its dependencies.

^{Originally posted by @Shane32 here.}