En fait, j'ai quand même l'impression qu'il y deux niveaux dans cette discussion:
1) La loi d'Hyrum dit que les utilisateurs vont être amenés à utiliser plus ou moins consciemment les propriétés concrètes de l'implémentation des API qui ne font pas partie de leur abstraction.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Le deuxième point n'est pas une constatation, c'est une décision de développement qu'on peut trouver discutable. Elle part du principe que l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux). Bien sûr, c'est pragmatique, et il y a plein de raisons pour lesquelles on voudrait appliquer 2. Mais ça n'a pas vocation à être une règle absolue, et typiquement dans le cas d'un logiciel libre, les devs n'ont pas de compte à rendre aux utilisateurs, et encore moins à ceux qui ne lisent pas la doc, ou ceux qui n'ont pas le temps d'assurer un peu de maintenance lors des changements de version des dépendances.
En fait, il y a quand même une asymétrie ici, puisque la dette technique est payée par les développeurs du logiciel, alors que la maintenance est payée par les utilisateurs. Appliquer le deuxième point c'est du "transfert de dette", c'est parfois raisonnable mais il y a plein de raisons de penser que ça n'est pas toujours une bonne idée.
[^] # Re: Dette technique...
Posté par arnaudus . En réponse au lien Hyrum's Law (ou ne pas changer une API même cassée). Évalué à 5.
En fait, j'ai quand même l'impression qu'il y deux niveaux dans cette discussion:
1) La loi d'Hyrum dit que les utilisateurs vont être amenés à utiliser plus ou moins consciemment les propriétés concrètes de l'implémentation des API qui ne font pas partie de leur abstraction.
2) Cette loi est utilisée comme raison pour limiter les changements dans l'implémentation des API.
Le deuxième point n'est pas une constatation, c'est une décision de développement qu'on peut trouver discutable. Elle part du principe que l'équipe de développement est au service des utilisateurs (c'est douteux), elle part aussi du principe que les devs ont une forme de responsabilité vis-à-vis de la manière dont les utilisateurs exploitent les fonctionnalités des logiciels (là aussi, c'est douteux). Bien sûr, c'est pragmatique, et il y a plein de raisons pour lesquelles on voudrait appliquer 2. Mais ça n'a pas vocation à être une règle absolue, et typiquement dans le cas d'un logiciel libre, les devs n'ont pas de compte à rendre aux utilisateurs, et encore moins à ceux qui ne lisent pas la doc, ou ceux qui n'ont pas le temps d'assurer un peu de maintenance lors des changements de version des dépendances.
En fait, il y a quand même une asymétrie ici, puisque la dette technique est payée par les développeurs du logiciel, alors que la maintenance est payée par les utilisateurs. Appliquer le deuxième point c'est du "transfert de dette", c'est parfois raisonnable mais il y a plein de raisons de penser que ça n'est pas toujours une bonne idée.