Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP/QRCoder2] Version number handling #542

Open
Tracked by #512
codebude opened this issue May 26, 2024 · 1 comment
Open
Tracked by #512

[WIP/QRCoder2] Version number handling #542

codebude opened this issue May 26, 2024 · 1 comment
Labels
qrcoder2 Everything related to QRCoder v2

Comments

@codebude
Copy link
Owner

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 always keep the version numbers of all packages identical? In other words, does a change in the generator logic that requires a 2.1.0 release for example also require the release of all other NuGet packages so that the version numbers run in parallel, or does each package have its own versioning?

@codebude codebude added the qrcoder2 Everything related to QRCoder v2 label May 26, 2024
@codebude
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
qrcoder2 Everything related to QRCoder v2
Projects
None yet
Development

No branches or pull requests

1 participant