Gérer soi-même ses numéros de version

bonjour :-)

(xpost et suivi)



qqn m'a indiqué :
https://semver.org/


Comment determine-t-on la "public API" ?
Y a-t-il une "règle de l'art" dans ce domaine ?


avez-vous un avis sur le plan que j'ai fait pour l'avenir ?

http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/ChangeLog.m
d?view=markup&pathrev=267 ( https://urlpetite.net/?wvy )



Est-ce correct d'incrémenter Z si ça respecte la condition de ne rien
changer de mon API publique, même si celle de GtkAda a été chamboulée ?

Est-ce que faire une mise à jour par rapport à GtkAda (c'est à dire une
dépendance), c'est considéré comme trop important pour Z, même si on ne
fait absolument rien d'autre ?



j'ai un exécutable unique qui fait GUI ou CLI selon une option qu'on lui
donne.

Je souhaite clarifier ça en le divisant en 2 exécutables, pour que
chacun s'occupe d'une interface sans s'occuper de l'autre - évidement
l'option correspondante disparait.

X ou Y ?



Au moment de l'analyse de texte (ou des arguments CLI) :

Jusqu'à quel degré est-il permis de réduire le laxisme et augmenter la
rigueur (sans rien changer de fondamental),
sans incrémenter le X (voire le Y, tant qu'on n'ajoute rien de concret) ?

(Un usager négligent de mon point de vue pourrait considérer ça comme
une perte de fonctionnalité, constatant que ce qui marchait ne marche
plus.)



Jusqu'à quel degré est-il permis de "forcer" des changements, pour
garder du code (instantané) propre, dans des cas où il n'est pas
possible de conserver une compatibilité totale (par exemple sur la
structure d'un type),
en espérant que les usagers sortant du schéma classique (par exemple
"déclarer une variable et lui appliquer des sous-programmes") seront
ultra-minoritaires ou inexistants,
sans incrémenter le X ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/