Sur la base de mon expérience de la gestion des dépendances au niveau de la plate-forme d'entreprise complexe et du contrôle de version des versions, je suis venu pour recommander une approche que j'aime appeler le contrôle de version semi-sémantique .
Fondamentalement, il repose sur Semantic Versioning 2.0 mais n'est pas aussi strict.
Segments de version semi-sémantique:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Format du segment de lancement principal:
MARKETTING.MAJOR.MINOR.PATCH
Chaque segment doit autoriser les caractères alphanumériques, mais des valeurs numériques pures sont recommandées pour les changements incrémentiels logiques.
Comme SemVer, je recommande les composants Major, Minor et Patch pour représenter les niveaux de compatibilité inverse, mais je recommande également d'ajouter un composant Marketing . Cela permet aux propriétaires de produits, aux épopées / groupes de fonctionnalités et aux préoccupations commerciales de remplacer le composant principal indépendamment des problèmes de compatibilité technique.
Contrairement à d'autres réponses, je ne recommande pas d'ajouter un numéro de build au segment principal. Au lieu de cela, ajoutez un segment post-version après un «+» (ex: 1.1.0.0 + build.42). SemVer appelle ces métadonnées de construction, mais je pense que le segment post-publication est plus clair. Ce segment est idéal pour déclarer les données de suffixe comme non liées aux informations de compatibilité dans le segment de version principal. Vos builds d'intégration continue peuvent alors recevoir le numéro de version précédente ajouté avec un numéro de build incrémentiel qui se réinitialise après chaque version principale (ex: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Certaines personnes aiment mettre le numéro de révision svn ici ou le git commit sha pour faciliter le lien avec le référentiel de code. Une autre option consiste à utiliser le segment post-version pour les correctifs et les correctifs, bien qu'il puisse être intéressant d'envisager d'ajouter un nouveau composant de version principale pour cela. Il peut toujours être supprimé lorsque le composant de correctif est incrémenté, car les versions sont effectivement alignées à gauche et triées.
En plus des segments de publication et de post-publication, les gens souhaitent souvent utiliser un segment de pré-publication pour indiquer des pré-versions presque stables telles que les alphas, les bêtas et les versions candidates. L'approche SemVer fonctionne bien, mais je recommande de séparer les composants numériques des classificateurs alphanumériques (ex: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalement, vous augmentez le segment de version en même temps que l'ajout du segment de post-version, puis supprimez le segment de pré-version lorsque vous le prochain segment de version principale (ex: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Des segments de pré-version sont ajoutés pour indiquer que la version de sortie est à venir, généralement juste un ensemble fixe de fonctionnalités pour des tests et un partage plus approfondis qui ne changent pas de minute en minute en fonction de plus de commits.
La beauté d'avoir tout cela défini sémantiquement d'une manière qui couvre presque tous les cas d'utilisation est que vous pouvez les analyser, les trier, les comparer et les incrémenter de manière standard. Ceci est particulièrement important lorsque vous utilisez des systèmes CI pour des applications complexes avec de nombreux petits composants versionnés indépendamment (comme des micro-services), chacun avec ses propres dépendances gérées.
Si vous êtes intéressé, j'ai écrit un analyseur semi-sémantique en ruby . J'avais besoin non seulement d'utiliser ce modèle, mais aussi de pouvoir gérer d'autres applications qui l'utilisaient.