Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.
[^] # Re: L'histoire se répète
Posté par totof2000 . En réponse au lien Flatpak is not the future et pourquoi l'auteur pense qu'on devrait développer pour GTK3 et pas GTK4. Évalué à 3.
Je ne suis pas sûr de comprendre ou tu veux en venir (mais peut-être parce que moi-ùmême je n'ai pas forcément été clair non plus dans ce que je voulais exprimer).
LA stabilité ne signifie pas forcément l'immobilisme. On peut être suffisamment stable en mintenant la rétrocompatibilité au maximum, et ne se limiter qu'aux breaking changes réellements essentiels, tout en continuant à avancer et à fournir des nouvelles fonctionnalités.
Python est un bon exemple : je ne suis pas un fan de python, je ne suis pas non plus convaincu par certains changements apportés par Python3, mais il faut reconaître que la transition entre Python 2 et python 3 s'est faite en douceur. Python 2 et python 3 ont été maintenus suffisamment longtemps pour que les gens puissent apporter les changements à leur code. Python2 fournissait des bibliothèques (future, six) permettant d'écrire du code proche de python 3. Et de ce point de vue, que l'on aime ou pas Python, tout a été fait pour que la transition se fasse dans les meilleures conditions.
A l'opposé il existe des outils et des frameworks (GTK est souvent cité pour ça, mais ça a été aussi le cas de certains frameorks Javascript côté serveur ou côté client) qui ont eu quelques soucis de manque de rétrocompatibilité, pour lesquels les devs (enfin ceux que je connaissais) se sont plaint de devoir passer plus de temps à gérer les changements des couches basses et à réécrire du code qui fonctionnait très bien jusqu'aux changements en question plutôt que de développer leurs fonctionnalités (et manque de bol ils ont eu à ce moment là à gérer des changements sur plusieurs dépendances qui se sont étalées suffisamment longtemps pour que ça pénalise leur travail).
J'ai moi-même bossé dans une équipe qui développait des composants pour un outil de déploiement qui utilisait Ansible en couche basse, et une des contraintes que l'on s'était imposé c'était de n'introduire des breaking changes uniquement quand c'était nécessaire, et de maintenir suffisamment longtemps les versions N-1 (en terme de correction de bugs) pour laisser suffisamment de temps aux utilisateurs pour faire la transition (leur métier n'étant pas de s'adapter aux outils de déploiement, mais d'écrire du code et de le déployer (avec l'infra sous-jacente) de la manière la plus simple qui soit.