C'est marrant que l'auteur prenne d'entrée l'exemple de l'élection du Doge de Venise comme exemple de processus «trop compliqué» et ça illustre bien la position de l'auteur sur la supériorité idéologique qu'il accorde à la simplicité, par delà tous les autres avantages : l'élection du [Doge]() était effectivement un processus byzantin, mais l'histoire lui reconnait néanmoins un mérite empirique indéniable : ce fut l'un des régimes les plus pérennes de toute l'histoire ! Ce système a perduré de 1268 jusqu'à la fin de la république de Venise en 1797 sans coup d'état ou affrontement pour le pouvoir, y compris dans les périodes difficiles, ce qui est bien assez rare pour être remarqué.
Sinon globalement l'article est assez inutile (voire carrément bête) :
It really feels like semantic versioning is about the software development world before always-on continuous software delivery systems. If you are working in this earlier software development world, then perhaps semantic versioning is okay for you.
Le concept de semver datant de 2010, c'est quand même une affirmation un peu bancal.
With modern CD systems, we want to simplify.
La «simplicité» érigée en dogme, même si en pratique on s'en fout si ça rend le système plus compliqué: plus loin dans le texte il dit :
But wait, you say, what about API's and compatibility? These should not be based on the release number! API's should do their own version management, independent of the build number.
Du coup au lieu d'avoir un numéro de version relativement simple qui donne toutes les infos dont on a besoin, il a un numéro de version débile qui ne sert à rien (à part à compter les versions) et un autre numéro de version censé contenir une info utile …
En pratique, le semver marche bien et facilite nettement le travail d'intégration entre différents composants d'une architecture modulaire, les seuls cas que j'ai rencontré où le semver n'est pas adapté sont :