Comment versionnez-vous vos projets?

StackOverflow https://stackoverflow.com/questions/142340

  •  02-07-2019
  •  | 
  •  

Question

Je comprends que Microsoft utilise ce modèle pour la gestion de versions de leurs produits: Major.Minor.Build.Revision.

Major est modifié lorsque les " développeurs " vouloir montrer qu'il y a un grand changement dans le logiciel et que la compatibilité en amont ne peut pas être assumée. Peut-être qu'une réécriture majeure du code est effectuée.

Le nombre mineur représente une amélioration significative dans l’intention de la compatibilité ascendante.

Le numéro de build est un petit changement, par exemple une recompilation de la même source.

La révision est utilisée pour réparer une faille de sécurité et doit être totalement interchangeable. La construction et la révision sont facultatives. Ces informations sont basées sur la classe de version MSDN .

Comment modifiez-vous vos projets et pourquoi les modifiez-vous de cette façon?

Était-ce utile?

La solution

Nous faisons généralement major.minor [.maintenance [.build]] où je travaille, mais cela semble varier un peu par projet.

Major / mineur identique à celui que vous avez mentionné. la maintenance serait incrémentée pour les petites corrections (de bogues) et générée à chaque fois que le serveur de génération était exécuté.

Autres conseils

Personnellement, j’aime utiliser un schéma qui se concentre sur le niveau de compatibilité en amont que les utilisateurs du projet / produit peuvent attendre:

Avant 1.0:

  • 0.0.1 = Première version
  • 0 .-. X = Mise à jour compatible avec les versions antérieures
  • 0.X.0 = Mise à jour incompatible avec la version précédente

Après 1.0:

  • -.-. X = Mise à jour sans modification d'interface
  • -. X.0 = Mise à jour avec ajouts d'interface compatible avec les versions antérieures
  • X.0.0 = Mise à jour incompatible avec les versions antérieures

Utiliser la compatibilité comme point central du numéro de version permet aux utilisateurs, en particulier si le produit est une bibliothèque, de déterminer s’ils peuvent ou non s’attendre à une mise à niveau transparente et sûre .

Je vois souvent Xyz où X est l'année suivant le numéro de version et yz le mois de l'année. C'est à dire. 201 est janvier, 2 ans après sa libération. C'est à dire. lors du lancement du produit en mai, son premier numéro de version est le 105. La sortie en février de l'année prochaine est le 202.

Nous mettons généralement la version de nos projets en fonction de la date de publication actuelle, AAAA.MM.DJ. *, et nous laissons le numéro de build générer automatiquement. Ainsi, par exemple, si nous avions une version aujourd'hui, elle serait 2008.9.26.BUILD .

J'utilise major.minor.point.revision, où point est une version ne contenant que des correctifs et la révision, la révision du référentiel. C'est facile et ça marche bien.

Je travaille sur de nombreux projets plus petits et j'ai personnellement trouvé cela utile.

PatchNumber.DateMonthYear

Il s’agit de petits outils Web permettant aux utilisateurs de savoir quand et comment la dernière mise à jour a été mise à jour.

PatchNumber est le nombre de versions qui ont été effectuées et le reste sert à montrer aux utilisateurs quand cela a été publié.

Major.minor.patch.build   avec le correctif étant la version de correctif ou de correctif.

Si vous pouvez obtenir le contrôle qualité par et si vous êtes sur SVN, vous pouvez utiliser la révision svn HEAD comme numéro de construction. De cette manière, chaque génération décrit son origine en termes de contrôle de code source et son contenu. Cela signifie que vous aurez des builds qui montent avec des trous (1.0.0.1, 1.0.0.34 ....)

Major.Minor.BugFix.SVNRevision

exemple: 3.5.2.31578

  • La révision SVN vous donne la paix très exacte du code envoyé au client. Vous êtes absolument sûr que ce correctif était là ou pas.
  • Cela aide également à trouver le bon PDB en cas d'erreur d'application. Faites simplement correspondre les révisions SVN sur votre serveur de construction, copiez le PDB dans l’emplacement EXE, ouvrez le débogueur et vous obtenez le suivi de la pile des incidents.

Je viens de faire Major.minor. Étant donné que je suis un développeur unique (avec de l'aide occasionnelle) travaillant sur une application Web, la plupart des gens se moquent bien des corrections mineures que je fais. Je me contente donc de parcourir les versions mineures au fur et à mesure que je rajoute de nouvelles fonctionnalités et des numéros de version majeurs lorsque je modifie / met à niveau quelque chose. Sinon, j'ignore simplement les petites corrections en ce qui concerne les numéros de version (bien que je possède des numéros de révision Subversion si je dois me référer moi-même).

Je viens d'avoir un numéro. La première version est 001. La troisième version bêta de la deuxième version est 002b3, et ainsi de suite. C’est juste pour des raisons d’esprit personnel, je n’ai rien de "sorti" pour le moment, c’est donc une théorie.

J'ai commencé à utiliser un pseudo-format similaire à Ubuntu: Y.MMDD

Cela aide pour plusieurs raisons:

  • il est plus facile de vérifier les exigences de version: if (version < 8.0901) die / exit / etc. ;
  • il peut être généré automatiquement dans votre processus de construction

Sur ce 2ème point (ruby & et rake): 

def serial(t)
   t = Time.now.utc if not t.instance_of?(Time)
   t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end

serial(Time.now)     #=> 8.0926
serial(Time.now.utc) #=> 8.0927

REMARQUE: t.strftime (& "% Y.% m% d &";). to_f - 2000 rencontre des inexactitudes en virgule flottante: 8.09269999999992

Avant, j'aimais la méthode de gestion de version de Nantucket pour leur compilateur Clipper dans les années 80:

Clipper Hiver 1984
Clipper Summer 1985
Clipper Hiver 1985
Clipper Automne 1986
Clipper été 1987

Oh et les superpositions ....

[a les larmes aux yeux]

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top