Canaux de publication¶
VisioForge publie ses paquets SDK .NET sur nuget.org fréquemment, souvent plusieurs fois par semaine. Tous ces builds ne sont pas destinés à la production, et cette page vous indique lequel prendre.
Numéros de version¶
Chaque version de paquet est une date : YYYY.M.D. 2026.8.16 a été produite le 16 août 2026. Les versions n'avancent que vers l'avant, et une version supérieure est toujours le build le plus récent.
Les paquets de runtime natif (VisioForge.CrossPlatform.*) portent leurs propres dates et suivent leur propre calendrier, car les runtimes de plateforme qu'ils encapsulent sont reconstruits indépendamment du SDK managé. Qu'un paquet managé et son compagnon natif portent des numéros de version différents est normal, ce n'est pas une incompatibilité.
Les deux canaux¶
| Stable | Quotidien | |
|---|---|---|
| Ce que c'est | Un build ayant passé une exécution complète des tests et désigné comme la version à utiliser | Tout autre build publié |
| Version | Une version YYYY.M.D ordinaire, sans suffixe | Une version YYYY.M.D ordinaire, sans suffixe |
| Comment l'identifier | Marquée stable sur son titre dans le journal des modifications | Toutes les autres |
| Pour qui | La production. C'est la recommandation par défaut | Prendre un correctif le jour où il arrive, et le tester |
Les deux canaux publient sur nuget.org comme des versions ordinaires : dotnet add package et l'interface NuGet vous proposeront donc le build le plus récent quel que soit le canal. Épinglez la version explicitement si vous voulez la stable.
Prendre la version stable¶
Nommez la version dans votre fichier projet plutôt que de laisser NuGet résoudre la plus récente :
<ItemGroup>
<PackageReference Include="VisioForge.DotNet.MediaBlocks" Version="2026.8.16" />
</ItemGroup>
Le journal des modifications la nomme : le titre de l'entrée stable indique ## 2026.8.16 - stable. Ce titre fait foi. Les numéros de version rencontrés ailleurs — dans un projet d'exemple, dans un extrait de la documentation — sont ceux dont ce fichier a été estampillé en dernier, et non une affirmation sur la version stable en cours.
Une nouvelle version stable est désignée environ une fois par mois.
Prendre un build quotidien¶
Prenez la version publiée la plus récente. C'est ce que vous obtenez par défaut avec dotnet add package sans version, et c'est le bon choix lorsqu'un correctif que vous attendiez vient d'être annoncé dans le journal des modifications : il est disponible le jour de sa publication et non en fin de mois.
La contrepartie est qu'un build quotidien embarque toutes les autres modifications faites ce jour-là.
Signaler un problème¶
Si un build introduit une régression chez vous, ouvrez un ticket en indiquant la version que vous utilisiez et celle vers laquelle vous êtes passé. Les deux numéros sont des dates : ils nous disent exactement quels changements se trouvent entre elles.