Release Channels¶
VisioForge publishes .NET SDK packages to nuget.org frequently — often several times a week. Not every one of those builds is meant for production, and this page tells you which one to take.
Version numbers¶
Every package version is a date: YYYY.M.D. 2026.8.16 was cut on 16 August 2026. Versions only move forward, and a higher version is always the newer build.
Native runtime packages (VisioForge.CrossPlatform.*) carry their own dates and move on their own schedule, because the platform runtimes they wrap are rebuilt independently of the managed SDK. A managed package and its native companion having different version numbers is normal, not a mismatch.
The two channels¶
| Stable | Daily | |
|---|---|---|
| What it is | A build that has been through a full test run and designated as the release to use | Every other published build |
| Version | An ordinary YYYY.M.D version — no suffix | An ordinary YYYY.M.D version — no suffix |
| How to identify it | Marked stable on its heading in the changelog | Everything else |
| Who it is for | Production. This is the default recommendation | Taking a fix the day it lands, and testing it |
Both channels publish to nuget.org as ordinary versions, so dotnet add package and the NuGet UI will offer you the newest build regardless of channel. Pin the version explicitly if you want the stable one.
Taking the stable release¶
Name the version in your project file rather than letting NuGet resolve the newest:
<ItemGroup>
<PackageReference Include="VisioForge.DotNet.MediaBlocks" Version="2026.8.16" />
</ItemGroup>
The changelog names it: the stable entry's heading reads ## 2026.8.16 - stable. That heading is the authority. Version numbers you find anywhere else — in a sample project, in a documentation snippet — are whatever that file was last stamped with, not a statement about which release is stable.
A new stable release is designated roughly once a month.
Taking a daily build¶
Take the newest published version. This is what you get by default from dotnet add package with no version, and it is the right choice when a fix you are waiting for has just been announced in the changelog: it is available the day it is published rather than at the end of the month.
The trade-off is that a daily build carries every other change made that day.
Reporting a problem¶
If a build introduces a regression for you, open an issue naming the version you were on and the version you moved to. Both numbers are dates, so they tell us exactly which changes are between them.