versionnage sémantique, corrections de bogues-versions des versions précédentes et précédence dans l'arborescence

Question

Nous utilisons semantic versioning. Supposons que nous ayons une version de logiciel avec un numéro de version de par ex. 2.1.1. En raison d'un changement d'API, la prochaine version a le numéro de version 3.0.0. Supposons maintenant qu'un bogue se trouve dans la version 2.1.1 et dans la version 3.0.0. Puisque certains clients utilisent toujours 2.1.1 et nous ne voulons pas les forcer à mettre à niveau vers une version 3.0.1 ou plus tard, nous fournissons une version de maintenance (correction de bogue) pour la version 2.1.1. Un numéro de version simple pour cette version pourrait être 2.1.2. Bien qu'aucun exemple n'est donné dans le defintion of precedence, je voudrais conclure que les règles impliquent 2.1.2 < 3.0.0 - ce qui signifie quoi? La version 2.1.2 a été publiée après 3.0.0 et la version 3.0.0 n'inclut pas toutes les corrections de bogues de 2.1.2. En fait, ces deux versions ne sont pas vraiment commandable, les versions (et les révisions sources correspondantes) ont maintenant une structure arborescente:

| 
2.1.1  (1) 
    |\ 
    | \ 
    | 2.1.2 (3) 
    | 
3.0.0  (2) 
    | 

Pour refléter cette structure d'arbre et éviter toute confusion, je préférerais un système de numéro de version comme ce qui suit:

| 
2.1.1  (1) 
    |\ 
    | \ 
    | 2.1.1+m (3) 
    | 
3.0.0  (2) 
    | 

(+m pour la libération de maintenance). Selon la définition de préséance sémantique versioning cela impliquerait encore 2.1.1+m < 3.0.0, mais pour nos clients que nous pourrions ajouter une règle pour x1.y1.z1 < x2.y2.z2 une version x1.y1.z1+m* est pas comparable à x2.y2.z2 (mais x1.y1.z1 < x2.y2.z2+m* détient toujours).

Existe-t-il des bonnes pratiques pour la gestion de version d'une arborescence? Ou ai-je eu quelque chose de mal à propos de la version sémantique?

Answer 1

Non, vous ne doit pas prendre n'importe quelle date de publication en commençant par des relations de précédence semver telles que 2.1.2 < 3.0.0. Tout ce que vous pouvez déterminer, c'est qu'il y a probablement eu des changements entre eux.

Si vous voulez des informations de date de construction, il serait raisonnable d'inclure dans les métadonnées de construction, mais ces métadonnées n'ont absolument rien à voir avec le concept de préséance semver. Cependant, un humain pourrait raisonnablement conclure que la version 2.1.2+201706010005 a probablement été construite après 3.0.0+201603151112.