Usage contraire au recommandation à la doc et changement de comportement

Ce changement entraîne-t-il une breaking change (changement de major) ?

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,

Je voudrais savoir si ces deux points entraînent une breaking change de ma bibliothèque : J’ai refactorisé en entier le code de mon application, l’API et les valeurs retournés reste les mêmes. Cependant ces changements peuvent entraîner une modification de comportement des Hacks (= bricolage, morceau de code pour agrandir la couverture et fonctionnalité de la lib -> par exemple ajout/modification de membre de la classe). Ces changements sont contraires au recommandation de la doc, à l’usage normal de l’API de la lib et des indications dans la doc.

Bon vol,

A.

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut,

Je crois qu’il y avait déjà eu des discussions là-dessus ailleurs, mais je les retrouve pas. C’était peut-être dans les commentaires de la bêta du tuto C++ en fait. Je ne sais plus.

Quoi qu’il en soit, les changements majeurs devraient théoriquement se fonder uniquement sur les interfaces publiques. Quand je dis interface, je pense à toutes les interfaces, que ce soit API, ou comportements ou autres. Et que quand je dis publique, ce n’est pas au sens du langage de programmation, mais au sens de ce qui est documenté pour un usage par l’utilisateur.

C’est à l’utilisateur d’être responsable et d’éviter d’utiliser des choses qui pourraient changer sans préavis.

Il y a quand même des exceptions : si ton code est très utilisé et qu’il est de notoriété publique qu’une grande partie des utilisateurs utilise un comportement particulier, même non documenté, alors ça devrait être un breaking change, parce que ça veut dire que de fait, l’interface publique est plus étendue que ce qui est présenté officiellement.

Si tu doutes, ça peut valoir le coup de noter ça comme majeur aussi. Comme ça, pas de surprise pour tes utilisateurs s’il y a de l’incompatibilité que tu n’avais pas prévue.

+4 -0
Auteur du sujet

Si tu doutes, ça peut valoir le coup de noter ça comme majeur aussi. Comme ça, pas de surprise pour tes utilisateurs s’il y a de l’incompatibilité que tu n’avais pas prévue.

Aabu

J’ai des tests assez large et un coverage à 99%, et j’essaye justement de ne pas changer de major avec ces changements.

Édité par anonyme

+0 -0

Cette réponse a aidé l’auteur du sujet

De ce que tu décris, ça me semble OK de garder la majeure inchangée. L’interface publique habituelle est inchangée. La privée, celle que tu recommandes explicitement de ne pas utiliser parce qu’elle peut changer d’une mineure à l’autre, change.

De plus, sinon, cela veut dire qu’à chaque fois que tu réécris (renommage, suppression, changement des retours…) une fonction à usage interne, tu devrais changer le numéro de majeure. Rien n’empêche de dire clairement dans la doc qu’il y a une API publique, dont tu garanties la compatibilité d’une mineure à l’autre, et le reste (API privée), que tu ne garanties pas, ou seulement entre les versions corrigeant les bugs.

Il y a bien des façons de passer à l’acte. Se taire en est une. Attribué à Jean-Bertrand Pontalis

+0 -0
Auteur du sujet

Je suis entrain de mettre en place la documentation avec un outil générateur de doc selon les commentaires mais ça m’oblige à refactoriser certaine partie de mon code pour avoir un retour de l’API cohérent et ordonné.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte