Comment faire des numéros de version ?

Question

Mon entreprise est la construction un produit. Il va être transféré par SVN. C’est un webapp donc fondamentalement il n’y aura jamais une version qui n’a pas certaines fonctionnalités en eux et donc pourrait toujours être étiquetée comme bêta. Mais puisqu’il va être un produit d’entreprise je ne veux vraiment pas la « watchout instable » là-bas. Alors, comment feriez-vous pour la gestion des versions ? 1.0 est stable ? La date de construction devrait être dans le numéro de version ? Dites-moi ce que vous en pensez !

Answer 1

[principaux].[mineur].[libération].[build]

majeur: Vraiment une décision de commercialisation. Êtes-vous prêt à appeler la version 1.0? La société ne considère ce fait comme une version majeure pour laquelle les clients pourraient avoir à payer plus, ou est-il une mise à jour de la version majeure actuelle qui peut être libre? Moins d'une R&D de décision et de plus en plus un produit de décision.

mineur: Commence à partir de 0 à chaque fois que le major est incrémenté. +1 pour chaque version qui va public.

version: Chaque fois que vous frappez une étape importante de développement et de la libération du produit, même en interne (par exemple pour AQ), par incrément. Ceci est particulièrement important pour la communication entre les équipes dans l'organisation. Inutile de dire, ne jamais relâcher le même "libération" deux fois (même en interne). Remise à 0 sur mineur++ ou grands++.

construire: Peut-être une révision SVN, je trouve qui fonctionne le mieux.

Answer 2

x.y.z.g

majoration de g sont instables. (ou RCs) la majoration en z sont stables et moyennes des corrections de bogues.
la majoration en y sont stables et moyennes de nouvelles fonctionnalités.
incréments en x sont stable, major version sans 100 % de compatibilité ascendante.

Answer 3

Une fois, j'ai écrit un complexe de "versioning" style guide" pour un grand projet de la mine. Le projet a échoué à se matérialiser, mais le guide de style est toujours disponible en ligne. C'est mon opinion personnelle, c'est peut-être utile (ou inspiration).

Méfiez-vous, c'est un long texte, et va dans la version du composant c. produits de contrôle de version et des trucs comme ça. Il se dit également de fortes opinions sur certains régimes de gestion des versions populaires dans l'OSS de la communauté, mais je les ai, donc je les exprime. ;-)

Je suis en désaccord avec l'aide de la Subversion numéro de révision, par exemple. Vous pourriez vouloir conserver une version tout en continuant le développement dans le COFFRE, de sorte que vous serez mis en place une branche de maintenance et de votre numéro de révision versioning va à l'égout.

Edit: en résumé, il fait la distinction entre la gestion des versions des fichiers source, des composants, et l'ensemble du produit. Il utilise un système de séparer x.y versoning pour les composants et le produit, avec une belle interdépendance entre les deux qui fait de traçage qui version de composant appartient à quelle version du produit trivial. Il parle aussi de comment gérer les alpha / beta / presse / patch cycles sans casser le système. En fait, c'est un modus operandi pour l'ensemble du cycle de développement, de sorte que vous pouvez choisir. ;-)

Edit 2: en tant Que suffisamment de gens ont trouvé mon article utile d'en faire une "Belle Réponse", j'ai commencé à travailler sur l'article de nouveau. PDF et LaTeX versions sont disponibles, une réécriture complète, y compris mieux la langue et des illustrations explicatives suivront dès que je trouve le temps. Merci pour vos votes!

Answer 4

Trouvez-vous l'inspiration de Wikipedia: "le Logiciel de versioning"

Un autre "nouveau" et "assez populaire" est la Sémantique de Versioning

Résumé:

Étant donné un numéro de version MAJEURE.MINEURE.PATCH, incrémenter le:

1. Version MAJEURE quand vous le rendre incompatible les changements de l'API,
2. Version MINEURE lorsque vous ajoutez des fonctionnalités à un rétro-compatible manière, et
3. Version de PATCH lorsque vous faites rétrocompatible avec les corrections de bug.

Des étiquettes supplémentaires pour la pré-release et de construire les métadonnées sont disponibles en tant que les extensions de la MAJEURE.MINEURE.Format de PATCH.

Answer 5

"Les numéros de Version" sont d'une question interne de votre système de contrôle de version. Communiqué de chiffres sont une autre affaire (et doivent être différents).

S'en tenir à un simple MAJEUR.Mise à jour MINEURE du système (comme v1.27), où MAJEUR est le niveau de compatibilité (la version 2.x est incompatible avec le ou au moins fortement différente de la version 1.x) et MINEUR est votre correction des rejets ou des améliorations mineures. Tant que vous suivez les X. Y format, vous pouvez également utiliser d'autres systèmes comme l'AN.MOIS (2009.12) ou de l'ANNÉE.LIBÉRATION (2009.3). Mais vraiment, vous êtes probablement mieux coller aux GRANDS.MINEUR, sauf si vous avez une bonne raison de ne pas.

Certainement ne pas utiliser tout ce qui ne rentre pas dans le X. Y format, comme il va rendre les choses difficiles pour les distributions, annonce, site web, etc. travailler avec vous, et rien que cela pourrait gravement affecter votre projet de popularité.

Utiliser les branches et les tags dans votre (de préférence distribué) système de contrôle de version pour marquer interne de numéros de version comme se rapportant à des MAJEURES et des mineures, respectivement.

Et oui, 1.0 doit être stable. Toutes les versions doivent être stables, sauf s'ils sont marqués alpha, bêta ou RC. Utiliser les Alphas connu brisée et incomplète. Les bêtas connu rompu. RCs pour "essayer; vous aurez probablement spot choses nous a manqué". Quoi que ce soit sans l'un de ces devrait (idéalement, bien sûr) être testé, bien connus, ont une mise à jour du manuel, etc.