Comment le versioning sémantique s'applique-t-il aux programmes sans API?

Dans http://semver.org/ ( ce qui, à mon avis, semble être la convention la plus largement utilisée dans la gestion des versions), il est recommandé d'augmenter le numéro de version principal lorsqu'un changement qui casse / modifie l'API est introduit.

Il y a deux scénarios liés mais je ne vois pas comment appliquer cette directive:

1. Que se passe-t-il si mon code ne propose aucune API? Comment dois-je versionner mon code?
2. Que se passe-t-il si mon code commence à proposer une API à un stade avancé de son développement?

Semver s'intéresse principalement à la gestion des versions des bibliothèques et des packages d'une manière qui évite les dépendances, dans ses diverses incarnations. Cependant, l’ idée de Semver peut être étendue à tout type de programme - tout morceau de code a une interface utilisateur ou est plutôt inutile.

• Une bibliothèque de programmation ou un service Web possède une API.
• Les logiciels grand public peuvent avoir une interface graphique.
• Les programmes en ligne de commande disposent d'un ensemble de commutateurs et d'options.
• Les fichiers de configuration sont également une interface utilisateur.

Prenons l'exemple d'un logiciel grand public, tel qu'un traitement de texte:

• Incrémentez le numéro de patch lorsque vous envoyez un correctif de bogue, par exemple: « bogue corrigé dans lequel l'application se bloque toujours à 00h00 le mardi ».
• Incrémentez le numéro de version mineur lors de l'ajout d'une nouvelle fonctionnalité, par exemple: « Ajout de la prise en charge du texte souligné ».
• Incrémentez la version principale lorsque vous révisez de manière significative l'interface utilisateur ou réécrivez tous les internes. Ex.: «Les barres d’outils utilisent trop d’espace écran. L'interface utilisateur est désormais fournie uniquement par le biais de gestes tactiles »- une telle modification aurait pour effet de casser les flux de travail existants.

Cependant, de nombreux problèmes que Semver essaie de résoudre n'existent pas en dehors du domaine de la gestion des dépendances. Dans les applications grand public, la version n'est pas seulement une version, mais également un atout marketing.

• Firefox et Chrome publient de nouvelles versions relativement fréquemment et incrémentent leur numéro de version principale à chaque version. Cela se traduit par un nombre de versions ridiculement élevé (les deux sont actuellement dans la trentaine). Un navigateur avec un numéro de version supérieur doit simplement être meilleur qu'un navigateur avec un numéro de version inférieur, non?

• Le numéro de version majeur du système d'exploitation OS X d'Apple est devenu partie intégrante du nom (X est 10 en chiffres romains), ce qui fait du numéro de version mineure le numéro de version majeur effectif.

• Le système d'exploitation Ubuntu utilise un schéma de gestion de versions year.month.patchlevel. Cela facilite la mémorisation de l’ancien système d’exploitation, mais rend beaucoup plus difficile la détermination des versions compatibles et de la durée de la prise en charge de chaque version.

• Le noyau Linux a modifié le numéro de version de 2.6.39 à 3.0.0, car 39il devenait un peu volumineux, et pour commémorer le 20e anniversaire de Linux.

• Le légendaire système de composition TeX de Donald Knuth utilise un numéro de version qui, à compter de la version 3, converge vers π en ajoutant un autre chiffre à chaque publication: 3.14159265…. Cela signifie que le système se rapproche de la perfection. De même, le système Metafont converge vers e : 2.7182818….

Ainsi, de nombreuses applications ne sont pas bien desservies par Semver. Choisissez un schéma de gestion des versions qui convient à vos utilisateurs (que ces utilisateurs soient des programmeurs ou des consommateurs) et maintenez la cohérence.