Versionnement sémantique : changement mineur ou majeur ?

Question

Sur versionnement sémantique la règle générale est d'augmenter le numéro mineur uniquement lorsque des fonctionnalités rétrocompatibles sont introduites, sinon le numéro majeur doit être augmenté à la place. Le site même approche mais avec une arithmétique différente, est utilisé par libtool .

J'ai une question concernant ce qui est considéré comme une modification rétrocompatible et ce qui ne l'est pas.

Imaginez que j'ai écrit une bibliothèque, et que l'en-tête public de cette bibliothèque contient un fichier typedef d'un type de données nommé foo . Dans la version 1.0.0, cette typedef ressemble à ça :

typedef struct foo_t {
    int x;
    int y;
} foo;

Puis je décide de changer le type de données, et dans la prochaine version, cela ressemblera à ceci :

typedef struct foo_t {
    int x;
    int y;
    int z;
} foo;

Je n'ai ajouté qu'un seul champ à la structure foo_t . Il semblerait qu'il s'agisse d'une modification rétrocompatible, cependant la structure ci-dessus est de facto une autre structure maintenant. Ce que j'ai fait n'est pas d'introduire une nouvelle fonction et de laisser intact tout le reste, mais plutôt de changer quelque chose qui était déjà là.

Le type de données ci-dessus est normalement utilisé pour échanger des données avec les fonctions de la bibliothèque, mais l'utilisateur peut l'avoir utilisé à d'autres fins. Si l'utilisateur avait écrit un programme utilisant la version 1.0.0 et que la dernière modification constitue une modification rétrocompatible, le programme de l'utilisateur doit compiler également avec cette nouvelle version.

Comment cette nouvelle version sera-t-elle appelée, 1.1.0 ou 2.0.0 ?

EDIT

Vous pouvez lire d'autres développements de cette discussion ici .

Answer 1

Il s'agirait d'un changement de version majeur. Les structures sont intégrées dans les programmes des utilisateurs finaux. C'est un changement radical que d'ajouter ou supprimer des membres ; dans tous les cas, la disposition a changé.

Citant le Guide pratique de la bibliothèque de programmes Linux - §3.6. Bibliothèques incompatibles :

Lorsqu'une nouvelle version d'une bibliothèque est binairement incompatible avec l'ancienne, le soname doit être modifié. En C, il existe quatre raisons fondamentales pour lesquelles une bibliothèque cesse d'être compatible binairement :

1. Le comportement d'une fonction change de telle sorte qu'elle ne répond plus à sa spécification initiale,

2. Les éléments de données exportés sont modifiés (exception : l'ajout d'éléments facultatifs à la fin des structures est acceptable), pour autant que ces structures ne soient allouées qu'au sein de la bibliothèque. ).

3. Une fonction exportée est supprimée.

4. L'interface d'une fonction exportée est modifiée.

Vous dites : "Le type de données ci-dessus est normalement utilisé pour échanger des données avec les fonctions de la bibliothèque, mais l'utilisateur a pu l'utiliser à d'autres fins." Si la structure était utilisée uniquement en interne et non exposée dans l'API publique, vous seriez d'accord. Mais il semble que l'utilisateur pourrait allouer une variable struct lui-même, ce qui signifie que c'est un changement de rupture.

Vous pouvez protéger votre bibliothèque de ce type de désabonnement en utilisant les éléments suivants structs opaques . Cacher le contenu des structures et faire en sorte que l'utilisateur ne fasse que passer des pointeurs. C'est exactement comme ça que FILE * fonctionne : la norme C ne définit pas la mise en forme des FILE et nous, en tant qu'utilisateurs finaux, ne savons pas ce qu'il y a dedans.