Release cycle fr FR

Cycle de mises à jour

ASF utilise le versioning courant C# qui est A.B.C.D. La version est en cours d’incrémentation après la libération de la version actuelle sur GitHub . Chaque version publiée à ce jour est disponible sur GitHub, à l'état gelé, et ne disparaîtra pas avec le temps. Il est donc toujours possible de revenir à n'importe laquelle d'entre elles, sans qu'il soit nécessaire de faire des copies automatiques.

En général, le versionnage ASF est très simple: nous utilisons des nombres de 0 à 9 au lieu de A, B, C et D. La modification de la version augmente de D, si le nouveau D donne le nombre 10, nous incrémentons C à la place et remettons D à 0. , etc. La publication d'une nouvelle version est censée être traitée comme un jalon ASF, une version avec un ensemble de fonctionnalités donné implémenté et prêt pour les tests / l'utilisation, sans provoquer de régression par rapport à la précédente. Sometimes we may decide that introduced changes are very important and bump C, B or even A instead, although that is quite rare (and usually indicates some breaking changes).

Les versions d'ASF sont divisées en deux catégories: les versions stables et les pré-versions.

Les versions stables sont supposées fonctionner correctement et sans aucune régression connue (au moment de la publication) par rapport aux versions précédentes. Nous avons tendance à publier la version stable soit après une longue période de tests préliminaires, soit en tant que version qui corrige des bogues de la version stable précédente, sans en introduire de nouveaux. In very rare scenario (e.g. Steam breaking change) we may also decide to release new stable version ASAP, if needed. En général, cependant, ces versions devraient fonctionner très correctement, car nous ne qualifions pas de version stable si cela aboutit à une dégradation de l’état de santé général par rapport à la version stable précédente. Bien sûr, cet "état de santé général" est basé sur les rapports et les commentaires que nous recevons lors du développement préalable à la publication. Il est donc malheureusement toujours possible que certains bogues disparaissent et soient découverts après la publication de la version stable, simplement parce que personne parmi nous n'a couru. dans la phase de développement. Heureusement pour nous, il est assez rare que cela se produise, et nous avons tendance à résoudre ce problème dès que possible dans une autre version stable ultérieure.

Les pré-versions sont plus fréquentes et introduisent généralement des modifications, des suggestions ou de nouvelles implémentations. La stabilité de la pré-version n'est pas garantie, bien que nous essayions toujours de faire des tests simples avant de la transmettre à GitHub, elle ne devrait donc jamais être une version complètement cassée en termes d'utilisation pratique. Le but principal des pré-versions est d’obtenir les commentaires d’utilisateurs plus avancés et d’attraper les bogues (le cas échéant) nouvellement introduits avant qu’ils n’atteignent une version stable. La qualité de ce travail dépend fortement du nombre de testeurs, des bogues signalés sur GitHub et des commentaires généraux.

Les pré-versions devraient ** généralement** fonctionner aussi bien que les versions stables, et la seule différence entre ces deux versions est simplement le fait d’être testé par plus d’utilisateurs. En effet, ASF est un projet évolutif, ce qui signifie qu’il devrait être possible de construire et d’utiliser à ** n’importe quel** moment donné, et la gestion des versions est créée pour votre commodité - en tant que jalon des changements entre les versions et un autre. Still, if you decide to use pre-releases, you should typically be a bit more advanced user, as pre-releases are usually work-in-progress smaller ASF milestones, and it's totally possible that even if something seems to be working decent, it may have stuff that isn't necessarily working or tested yet - tracking ASF development on GitHub and carefully reading changelogs is the minimum that you must do if you want to use pre-releases (for your own good). En plus de cela, il y a des moments où nous testons activement quelque chose de spécifique, comme un changement de configuration, un nouveau code réécrit pour un objet donné ou des changements fondamentaux. Always read changelog in this case, as such pre-release version could be more unstable than other ones.

Please note that newly introduced features and changes may be undocumented (e.g. on the wiki) until some time later, as documentation is usually written once final code of given feature is ready (to save us time rewriting documentation each time we decide to modify the feature we're currently working on). Due to the fact that pre-release may contain work-in-progress code that doesn't have a final form yet, documentation will arrive at later stage of the development. Same thing applies to general changelog that may be unavailable for given pre-release until some time later. Par conséquent, si vous décidez d’utiliser la version préliminaire, préparez-vous à regarder dans ASF ** **de temps en temps.

Bien sûr, le manque de documentation ne concerne ** seulement** les pré-versions - chaque version stable doit toujours disposer de la liste complète des modifications et de la documentation sur le wiki dès sa publication.

A pre-release version may be considered stable after some time. Cela est particulièrement vrai si aucune modification n'est apportée entre-temps et si la version bump n'a aucun sens uniquement pour des raisons de stabilité de la publication. Cela se produit également très souvent lorsque la pré-publication est considérée comme "candidate à la publication stable", car elle permet aux utilisateurs expérimentés de la tester avant qu'elle ne devienne stable. Le risque d'introduction de bogues est donc beaucoup plus faible. C'est donc le schéma le plus courant il s’agit des communiqués ASF:

Stable 1.0 -> Pre 1.1 -> Pre 1.2 -> ... -> Pre 1.7 (RC) -> Stable 1.7 (same as Pre 1.7)

En général cependant, les versions ASF sont publiées lorsqu'elles sont prêtes, ce qui entraîne un calendrier de publication non prévisible. Il existe généralement une pré-version à la fin de toute fonctionnalité majeure ou modification en cours, et une version stable si aucun bogue n’est détecté après un certain temps (quelques jours) depuis que la pré-version est disponible. Nous visons plus ou moins une version stable par mois, sauf s’il ya des problèmes critiques à résoudre ou un problème similaire. Les pré-versions se produisent au besoin lorsque nous pensons qu’il ya suffisamment de données à tester depuis la publication de la dernière. En fonction de l’actualité du développement d’ASF, il peut s’agir de quelques une à une douzaine de pré-versions entre chaque version stable.

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. Si vous souhaitez voir tous les changements survenus d’une version à l’autre, veuillez utiliser GitHub pour cela.

Le projet ASF est alimenté par un processus d'intégration continue et testé par deux services indépendants: AppVeyor qui teste ASF sous Windows et Travis qui teste ASF sous Linux et OS X. Chaque supposé être reproductible, il ne devrait donc pas y avoir de problème pour saisir le code source (inclus dans la version) de la version donnée et le compiler en recevant le même résultat que celui disponible sous forme binaire.

En plus des versions stables et des pré-versions d'ASF, vous pouvez également trouver la dernière version automatisée d'AppVeyor ici, qui est généralement construite à partir de la dernière mise à jour validée, pas encore incluse. En raison de l’automatisation et de l’absence de tout test, ces versions ne sont ** PAS ** prises en charge, et ne sont généralement disponibles que pour les développeurs qui ont besoin de saisir le dernier instantané ASF GitHub sous forme d’objet. alors ils n'auront pas besoin de se compiler. Rien ne garantit que ASF à l'état maître fonctionnera correctement. Dans de rares cas, ces versions peuvent également être utilisées pour vérifier si un problème ou un bogue donné a été validé, sans attendre le changement d'atterrissage en version préliminaire. Si vous décidez d'utiliser ces versions automatisées, assurez-vous de posséder des connaissances suffisantes sur ASF, car il s'agit du "niveau" le plus élevé de logiciels ayant fait l'objet d'un bug. À moins que vous n'ayez une bonne raison, vous êtes généralement à la pointe de la technologie en matière de suivi des générations de pré-version. Les versions d'AppVeyor sont proposées en complément des pré-versions, principalement pour vérifier si le problème particulier sur lequel nous travaillons a été résolu. à présent. Ces versions ne doivent être utilisées dans aucun environnement de production.