@Kritner from the CodingBlocks slack (https://www.codingblocks.net/slack) has written blog posts (2021-10-01, 2018-10-10) discussing how to use a single file to define version of multiple projects and their dependencies, making versioning easier to track and update.

Current System

ScottPlot version and all its dependency package versions are defined in individual csproj files:

• ScottPlot.csproj
• ScottPlot.WinForms.NUGET.csproj
• ScottPlot.WPF.NUGET.csproj
• ScottPlot.Avalonia.NUGET.csproj

A versioning-bumping script is manually run to increment ScottPlot version project-wide:

• Versioner/Program.cs

Proposed System

• Use a central file to store ScottPlot version
  • This should be used for Version, AssemblyVersion, and FileVersion
  • Notice that the first is x.x.x and the other two are x.x.x.0 (that fourth number is important)
• Use a central file to store versions of all dependencies that we want constrained (not necessary all packages).
  • ⚠️ Let's be careful which version of System.Drawing.Common is used in the core packages. We found that it this package can be upgraded in old solutions, but it breaks them such that they cannot be downgraded again (Which version of System.Drawing.Common should ScottPlot depend on? #1004). For this reason we probably want to keep targeting 4.6.1 for the primary library packages, although tests and demo applications may use newer versions.
• Consider whether to use GitHub Actions to automatically bump the version number before building and publishing NuGet packages in the cloud. See .github/workflows/ci.yaml

Potential Drawbacks

• Old versions of Visual Studio may be unable to use the graphical NuGet package manager. I'm not sure about how widely supported central package management is.
  • I think this is okay because it's unlikely typical users working in the source code of this project will need to add NuGet packages.