Qu’est-ce qu’une « version »?

Vista, Xp, alpha, beta, 2.0… Les versions sont omniprésentes dans notre quotidien. Mais, dans le fond, comment définit-on une (bonne) version? Voici quelques éléments de réponse qui, bien qu’ils s’intègrent dans une réflexion globale par rapport à la gestion des versions par Composer, dépassent largement ce cadre.

Versioning: Tag vs branch

Selon Wikipédia, « une version d’un logiciel correspond à un état donné de l’évolution d’un produit logiciel utilisant le versionnage ». On connaît tous les principaux systèmes de versionnage: Git, Svn, Mercurial, … Mais, dans ce flux de révisions, qu’est-ce qui distincte précisément une version?

On peut distinguer (par exemple dans Git) deux types de références potentielles: les branches et les tags. Bien sûr, tous deux pointent sur un commit. Mais une différence intrinsèque les distingue néanmoins:

  • Un tag marque un point dans le temps qui ne doit plus changer. Il désigne un commit invariable.
  • A l’inverse, une branche est en évolution (du moins potentielle). Il désigne une succession de commit.

Seul, donc, le tag peut être assimilé à une version stable d’un logiciel, dans la mesure où une version désigne justement un état invariable du code. Toutefois, il n’est pas rare de devoir utiliser des versions instables, essentiellement lors du développement, et donc notamment des branches.

Cycle de développement d’un logiciel

Qu’est-ce qu’une branche « stable »? Car une branche stable peut contenir des bugs, et donc présenter une certaine instabilité applicative. Ca aussi, on le sait tous… Il s’agit donc d’une convention, et on peut ainsi distinguer plusieurs grandes phases de stabilité, correspondant au cycle de vie traditionnel des logiciels avant la release finale:

Version dev
La version est en cours de développement. Aucune stabilité n’est garantie.
Version alpha
La version est développée mais en cours de test en interne.
Version beta
La version est ouverte à un public restreint, lequel peut remonter les problèmes.
Version RC (Release Candidate)
La version est ouverte à un public restreint, mais ne doit normalement plus contenir de bugs.
Version stable
La version est ouverte au public et est sensée ne plus contenir de bugs.

Semantic versioning (SemVer)

Par essence, le nom d’une version possède une valeur forte. Il représente une évolution déterministe et indique un état particulier que l’on doit pouvoir identifier de manière sémantique ou symbolique. Le nommage sémantique implique une signification, tandis qu’un nommage symbolique peut être arbitraire.

Dans un but d’harmonisation sémantique (et pas symbolique), la Semantic Versioning 2.0.0 (SemVer) présente un standard de nommage de version. Ce système est essentiellement basé sur trois nombres séparés par des points (par exemple "2.1.5") définissant de manière logique les modifications que peut subir un code:

  • Le premier numéro correspond à la version majeure. Un saut de version majeure implique des modifications dans votre API existante. Il n’y a donc pas de rétrocompatibilité qui soit assurée.
  • Le deuxième numéro correspond à la version mineure. Un saut de version mineure implique l’ajout de fonctionnalités, mais assure la rétrocompatibilité.
  • Le troisième numéro correspond à des patch apportés. Il s’agit de corrections de bug.
  • Séparé par un tiret, il est aussi possible de rajouter le degré de stabilité (voir les différents types de stabilités).

Conclusion

Une version est un état du code déterminé grâce au versioning, et facilement identifiable grâce au standard de nommage SemVer.

Un tel versioning aura donc notamment un impact sur votre git flow.

Nous verrons dans les prochains articles que c’est sur cette base que Composer a élaboré son système de contrainte de version.

3 réflexions au sujet de « Qu’est-ce qu’une « version »? »

  1. Ping : Bonnes pratiques Composer: gérer les versions

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>