Existe-t-il une définition standard de ce qui constitue une modification de version?

Question

Je suis actuellement dans l'enfer bureaucratique de mon entreprise et j'ai besoin de définir ce qui constitue les différents niveaux de changement de logiciel dans nos programmes de test. Nous avons une pratique approximative que nous suivons en interne, mais je cherche une norme (si elle existe) pour référencer dans notre système Qualité. Je reconnais que les systèmes peuvent varier considérablement entre les développeurs, mais en fin de compte, je cherche un guide de «meilleure pratique» pour ce qui constitue un changement majeur, un changement mineur, etc. Je voudrais référencer un document publié dans ma soumission à notre système qualité pour Objectifs ISO si possible.

Pour clarifier le logiciel développé dans ma société est utilisé en interne pour l'automatisation des tests de semi-conducteurs. Nous ne vendons pas ce code et les versions sont vraiment réservées à la consignation. Nous utilisons les changements x.y.z pour effectuer le niveau de signature et d'approbation nécessaire pour la publication.

Answer 1

Une bonne pratique consiste à utiliser 3 numéros de révision du niveau:

xyz

x est la principale y est le mineur z sont des corrections de bugs

L'important est que deux logiciels les versions avec le même x devraient avoir une compatibilité binaire. Une version du logiciel avec un y plus grand qu'un autre, mais le même x peut ajouter des fonctionnalités, mais n'en supprimer aucune. Cela assure la portabilité dans le même numéro majeur. Et finalement z ne devrait pas changer de comportement fonctionnel, sauf pour les corrections de bugs.

---

Edit:

Voici quelques liens vers des systèmes de révision-utilisés: nombre

• http://en.wikipedia.org/wiki/Software_versioning
• http://apr.apache.org/versioning.html
• http://www.advogato.org/article/40.html

Answer 2

pour agrandir ce que @lewap dit, utilisez

xyz

où les changements de niveau z sont presque entièrement des corrections de bugs qui ne changent pas d'interfaces ou comportant des systèmes externes

où les changements de niveau y ajoutent des fonctionnalités et peut modifier l'interface UI/API en plus de corriger des bogues plus graves qui peuvent impliquer des systèmes externes

où les changements de niveau x impliquent tout, depuis une réécriture/redéfinition complète jusqu'à la simple modification des structures de base de données en bases de données changeantes (c.-à-d. d'Oracle à SQLServer) - dans d'autres rien de mots qui ne sont pas une baisse de changement qui nécessite un processus de « port » ou « conversion »

Answer 3

Je voudrais ajouter numéro de version au format x.y.z:

x.y.z.construire

x = changement majeur fonction
y = changement de fonction mineure
z = corrections de bug que
build = incrémentée chaque fois que le code est compilé

Y compris le numéro de build est essentiel à des fins internes où les personnes essayons de comprendre si oui ou non un changement particulier est dans les binaires qu'ils ont.

Answer 4

Je pense qu'il pourrait différer si vous travaillez sur un logiciel interne par rapport à un logiciel externe (un produit).

Pour les logiciels internes, l'utilisation d'un schéma formellement défini ne posera presque jamais de problème. Cependant, pour un produit, la version ou le numéro de version est dans la plupart des cas une décision commerciale ne reflétant aucun critère technique ou fonctionnel.

Dans notre société le x.y dans un schéma de numérotation x.y.z est déterminé par le marketing des garçons et des filles. Le z et le numéro de build interne sont déterminés par le département R & D et retournent dans notre système de contrôle de révision et sont liés au sprint dans lequel il a été produit (le sprint est le terme Scrum pour une itération). De plus, la définition formelle d'un certain niveau de compatibilité entre les versions et les versions pourrait vous amener à vous déplacer très rapidement ou à ne pas bouger du tout. Cela peut ne pas refléter les fonctionnalités supplémentaires.

Answer 5

Je pense que la meilleure approche pour vous d'expliquer cela à vos collègues est par des exemples tirés de progiciels bien connus et réussis, et la façon dont ils abordent les versions majeures et mineures.

La première chose que je dirais, c'est que la notation majuscule.minor pour les versions est une invention relativement récente. Par exemple, la plupart des versions d'UNIX avaient des noms (qui incluaient parfois un nombre sans signification) plutôt que des numéros de version. Mais en supposant que vous vouliez utiliser major.minor, la numérotation, alors le nombre majeur indique une version qui est fondamentalement incompatible avec beaucoup de choses qui se passaient auparavant. Considérez le passage de Windows 2.0 à 3.0 - la plupart des applications 2.0 ne s'intégraient tout simplement pas dans les nouvelles fenêtres superposées dans Windows 3.0. Pour les applications moins globales, un changement radical dans les formats de fichiers (par exemple) pourrait être une raison pour un changement de version majeur - WP & Les applications graphiques fonctionnent souvent de cette façon.

L'autre raison d'un changement de numéro de version majeur est que l'utilisateur remarque une différence. Encore une fois, cela était vrai pour le passage de Windows 2.0 à 3.0 et était responsable du succès de ces derniers. Si votre application semble très différente, c'est un changement majeur. A Pour le numéro de version mineur, il est généralement utilisé pour indiquer un canal qui est en fait assez important, mais qui ne sera pas perceptible par l'utilisateur. Par exemple, les différences internes entre Win 3.0 et Win 3.1 étaient en fait assez importantes, mais l'interface est restée la même.

En ce qui concerne le troisième numéro de version, peu de gens savent que cela signifie vraiment et moins de soins. Par exemple, dans mon travail de tous les jours, j'utilise la version 3.4.5 du compilateur GNU C++ - en quoi cela diffère-t-il de 3.4.4 - Je n'en ai aucune idée!

Answer 6

Comme je l'ai déjà dit dans une réponse à une question similaire: La terminologie utilisée n'est pas très précise. Il y a un article décrivant les cinq dimensions pertinentes. Les outils de gestion de données pour le développement de logiciels n'ont généralement pas tendance à en prendre en charge plus de trois simultanément.Si vous voulez soutenir les cinq que vous devez décrire un procesus de développement:

• Version (sémantique: modification)
• View (sémantique: équivalence, dérivation)
• Hiérarchie (sémantique: Comporte)
• Statut (sémantique: approbation, accessibilité)
• Variant (sémantique: variations de produits)

Peter van den Hamer et Kees Lepo eter (1996) Gestion des données de conception: les cinq dimensions des cadres de CAO, de la gestion de la configuration et de la gestion des données de produit, Actes de l'IEEE, vol. 84, No. 1, January 1996