Quelle est votre méthode préférée pour nommer vos versions logicielles? Comme Microsoft: alpha - bêta - final - service pack ... Comme Google: beta gmail - beta - beta - beta - :) Comme certains logiciels: 0.2 - 0,3 à 0,9999 ...Quelle est votre méthode préférée pour nommer vos versions logicielles?
Major.Minor.Release.Build
Bien que les incréments Release et Build ne doivent pas contenir de «changements de rupture» (par exemple, avoir un format de fichier différent pour stocker les documents), je ne suis pas absolument sûr que les versions mineures sont autorisées.
La signification de l'alpha, bêta sont suffixes pour moi:
Alpha/Preview: Hey, je suis quelque chose que je veux montrer. Bêta: L'ensemble de fonctionnalités est complet jusqu'à présent, mais il reste quelques bogues. Release Candidate: Je pense qu'il ne reste plus aucun bogue (majeur). Final: Il pourrait y avoir encore des bugs, mais je dois libérer à un moment donné ;-).
Je préfère la prototype, alpha, bêta, méthode GA. Cela me permet de communiquer l'état actuel du logiciel aux utilisateurs/clients. Avec cela, je fournis les numéros de version .2, .3, .4.
Nous ne proposons pas de logiciel alpha/bêta à nos clients. Par conséquent, nous utilisons simplement:
(où x, y = 1,2, ...)
Pour les petits logiciels juste Major.Minor. Si Major change - certains fichiers d'entrée ne sont pas compatibles avec la version précédente. Nous ne distribuons pas de logiciel aux clients, donc la même version est pour les tests et pour la version finale.
Microsoft utilise la numérotation des versions ainsi que les noms alpha, bêta et GA. Je pense que la dénomination des versions dépend beaucoup de ce que vous essayez d'accomplir. Si vous libérez quelque chose pour la consommation et que vous n'essayez pas de collecter des données à partir d'une période bêta, n'appelez pas cela bêta. Si vous n'essayez pas de prévisualiser la technologie, ne l'appelez pas alpha. Je travaille principalement avec des applications web à l'heure actuelle, et nous numérotons simplement nos versions comme des entiers incrémentants quand nous les déployons (1, 2, 3, 4, 5, etc.).Il n'y a aucune raison d'avoir à entrer dans une logique de nommage compliquée si personne ne se soucie des versions de toute façon.
La façon dont nous avons nommé nos versions est généralement le numéro de phase. La plupart de nos contrats étant des projets gouvernementaux, nous déploierons la première version, puis nous exécuterons la Phase 2, la Phase 3 et la Phase 4 au fur et à mesure que l'entité décidera d'avancer avec de nouvelles fonctionnalités.
Certains noms de projets de logiciels libres sont publiés après la date de leur publication. Par exemple, Ubuntu 8.04 a été publié en avril 2008 et Ubuntu 6.06 a été publié en juin 2006. Mais Ubuntu n'est pas la seule distribution Linux qui utilise cette méthode.
Bien sûr, chaque version d'Ubuntu a aussi un nom de code qui est chaque fois un animal différent, combiné avec un adjectif allitérateur (l'adjectif sert également de raccourci cutesy pour les initiés). Chaque version remonte dans l'alphabet afin que les gens se souviennent facilement où placer un communiqué dans le flux régulier. Par exemple:
Par exemple 6,06, pimpant drake 6.10, TEF énervée 7,04, fougueuse fauve 7.10, Gutsy Gibbon
Je préfère la notation du noyau Linux: major.minor.release.build, mais je rarement utiliser la partie .build, et je n'utilise pas de nombres pairs/impairs pour les mineurs stables/en développement.