FAQ sur le versioning sémantique

Voici un article qui fait suite à la publication du « Guide complet sur le versioning sémantique« . J’ai regroupé les 8 questions les plus courantes que vous pouvez vous poser sur ce sujet !

1. Comment dois-je traiter les révisions dans la phase initiale de développement : 0.y.z ?

La chose la plus simple à faire est de démarrer la version initiale de votre projet à 0.1.0, puis d’incrémenter la version mineure pour chaque évolution ultérieure, jusqu’à ce que vous soyez prêts pour une version 1.0.0.

2. Comment puis-je savoir quand publier 1.0.0?

Si votre logiciel est utilisé en production, il doit déjà être en 1.0.0, au minimum.

3. Cela n’est pas décourageant de devoir augmenter de version aussi souvent ?

La version 0.x.y concerne surtout un développement rapide. Si vous modifiez votre API tous les jours, vous devez toujours être dans cette version 0.x.y, ou sur une branche de développement distincte travaillant sur la prochaine version majeure.

4. Si même les petites modifications incompatibles avec l’application existante requièrent une augmentation de version majeure, ne finirais-je pas à la version 42.0.0 très rapidement?

En fait, c’est une question de prévoyance. Les modifications qui sont incompatibles ne devraient pas être introduites à la légère dans un logiciel, surtout si celui-ci a beaucoup de dépendances. Il est recommandé d’attendre plusieurs modifications de ce genre et de les introduire en même temps grâce à une nouvelle version majeur.

5. La documentation de l’ensemble de l’API publique représente trop de travail !

C’est votre responsabilité en tant que développeur professionnel de documenter correctement un logiciel destiné à être utilisé par d’autres. La gestion de la complexité du logiciel est une partie extrêmement importante pour le maintien d’un projet efficace, ce qui est difficile à faire si personne ne sait comment utiliser votre logiciel. Vous y gagnerez à coût sûr à long terme.

6. Que dois-je faire si j’introduis accidentellement une modification incompatible avec la version antérieur?

Dès que vous vous rendez compte que vous avez cassé la spécification du versioning sémantique, corrigez le problème et lancez une nouvelle version mineure qui corrige le problème et rétablit la compatibilité ascendante. Documentez ensuite la version de bug et informez vos utilisateurs du problème pour qu’ils soient au courant.

7. Que dois-je faire si je met à jour mes propres dépendances sans modifier l’API publique?

Cela serait considéré comme compatible car cela n’affecte pas l’API publique. Vous devrez déterminer si la modification est un patch ou une modification de niveau mineur en fonction de la mise à jour de vos dépendances : vous corrigez un bug ou vous introduisez de nouvelles fonctionnalités ?

8. Comment puis-je gérer les fonctionnalités « deprecated » ?

La suppression de fonctionnalités fait partie du processus normal de développement d’un logiciel. Lorsque vous désactivez une partie de votre API publique, vous devez faire deux choses :

  1. Mettre à jour votre documentation pour informer les utilisateurs de la modification.
  2. Emettre une nouvelle version mineure avec la dépréciation en place. Avant de supprimer complètement la fonctionnalité dans une nouvelle version majeure, il devrait y avoir au moins une version mineure qui contient la dépréciation afin que les utilisateurs puissent passer en douceur sur votre nouvelle API.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s