Release cycle fr FR

Cycle de mises à jour

ASF utilise le versioning C# courant avec 4 chiffres, écrit en A.B.C.D. La version donnée est toujours gelée, pointant vers un code source fixe à partir duquel elle a été construite (empaquetée avec la version). Nous n'avons pas l'intention de supprimer toute version publiée précédemment, tant que notre hébergeur (GitHub) restera bien à même de les conserver pour un avenir indéfini. pour que vous puissiez revenir en toute sécurité à l'un d'eux sans avoir besoin de faire des autocopies.

En général, en termes de version ASF, nous faisons de notre mieux pour suivre semver versioning de MAJOR. INOR.PATCH sur les 3 chiffres les moins significatifs - B.C.D. Ces trois nombres sont directement liés au code ASF. The most significant A number indicates changes with a scope that goes beyond ASF codebase itself, usually directly affecting the foundation of the program.

ASF en tant que projet vise à avoir plus ou moins une version de fonctionnalité par mois, indiqué par une bosse de numéro C. Afin de rendre cette version possible, nous avons de plus petites pré-versions dédiées aux utilisateurs avancés, qui servent de jalons plus petits des changements qui sont publiés au besoin quand il y aura suffisamment de changements depuis la dernière pré-publication pour se concentrer. Finalement quand une pré-publication finale sera déterminée à être stable et suffisamment mature sans aucune régression critique connue qui devrait être corrigée par rapport à la version stable précédente, il sera promu à la nouvelle version stable, tout en ouvrant un nouveau cycle mensuel pour la suivante.

Alors que nous faisons de notre mieux pour nous assurer que même nos pré-versions sont relativement stables, il faut noter que les pré-versions de la version doivent être soigneusement évaluées lorsqu'elles sont exécutées dans n'importe quel environnement de production. Pre-releases might have critical bugs and otherwise broken functionality, which is exactly why we're releasing them to begin with - so we can avoid all of that mess in our stable builds and offer reliable software. Si vous n'êtes pas prêt à accepter un risque accru qui vient de l'utilisation d'un logiciel potentiellement instable, évitez d'utiliser nos versions pré-release et maintenez avec notre dernière version stable à la place, qui est plus approprié pour la majorité des utilisateurs.

En fonction du nombre de changements dans le cycle, il y aura généralement un seul recul de version C (à partir de la version stable précédente), et D augmentent pour chaque pré-version au besoin. Cependant, lors de l'introduction de changements avec une portée beaucoup plus grande, en particulier les changements de rupture, le cycle pourrait commencer depuis (ou basculer au milieu) B ou même A bump - ce changement indique que le cycle de publication actuel a un potentiel d'être plus instable que d'habitude, et devrait être testé avec soin. Gardez à l'esprit que les changements que nous apportons ne concernent que la version stable publiée précédemment, nous ne suivons pas le versionnage entre les pré-versions dans un cycle lui-même, ce qui signifie que la version 1. .1.2 pourrait avoir une nouvelle fonctionnalité que 1.0.1. ne l'a pas fait, tant que la version stable précédemment marquée provient de la famille 1.0.0.X. De même, il pourrait y avoir des changements majeurs de rupture même sur deux pré-versions du même cycle, ce qui est particulièrement vrai lorsque nous décidons encore de la forme finale des fonctionnalités nouvellement introduites ou similaires.

Mise à jour de la version	Semver	Exemple de modifications
A		Changements majeurs de l'exécutable .NET, changements de fondation, changements cassés qui dépassent le code de base d'ASF, des choses qui pourraient manger votre chat
B	Principal	Modifications mineures du runtime .NET, cassant les modifications de la base de code ASF, modifications majeures du code qui vont au-delà de la classification mineure
C	Mineur	De nouveaux cycles mensuels, introduisant généralement de nouvelles fonctionnalités, commandes, propriétés de configuration ou autres modifications qui ne brisent pas les configurations existantes
D	Patch	Nouvelles pré-versions qui font partie du cycle existant (indiqué par un nombre plus significatif), corrections de bogues critiques aux versions stables existantes qui n'introduisent aucun changement de code au-delà du nécessaire

Veuillez noter que les nouvelles fonctionnalités et modifications peuvent ne pas être documentées (p. ex. sur le wiki) jusqu'à un certain temps plus tard, car la documentation est généralement écrite une fois que le code final de la fonctionnalité donnée est prêt (pour nous faire gagner du temps à réécrire la documentation chaque fois que nous décidons de modifier la fonctionnalité sur laquelle nous travaillons actuellement). En raison du fait que les pré-versions peuvent contenir du code en cours de réalisation qui n'a pas encore de formulaire définitif, peut arriver à un stade ultérieur du développement. Il en va de même pour le changelog général qui pourrait ne pas être disponible pour la pré-version donnée jusqu'à un certain temps plus tard. Par conséquent, si vous décidez d’utiliser des pré-versions, soyez prêt à regarder dans ASF communique de temps en temps. Bien sûr, le manque de documentation s'applique à seulement aux pré-versions - chaque version stable doit toujours avoir un journal des modifications complet et de la documentation sur le wiki au moment de sa publication.

Le changelog précis qui compare une version à une autre est toujours disponible sur GitHub - avec les modifications et les modifications de code. Dans les versions, nous avons tendance à ne documenter que les modifications que nous considérons importantes entre la dernière version stable et la version actuelle. Ce bref journal des modifications n'est jamais complet, donc si vous souhaitez voir chaque changement qui s'est produit entre une version et une autre (comme les mises à jour de nos dépendances) - veuillez utiliser GitHub comparaison pour cela.

Le projet ASF est alimenté par notre processus d'intégration continue . Chaque version est censée être reproductible, donc il ne devrait pas être problématique de récupérer les sources (incluses dans la version) d'une version donnée et de vous compiler en recevant le même résultat que celui disponible via nos binaires précompilés. Nous évitons généralement de compiler nous-mêmes des versions, tant que les systèmes sont opérationnels, les binaires publiés proviennent directement de notre processus de CI .