Beaucoup d'informations essentielles de Joshua dans les messages des derniers jours 
Alors, le plus important : laisser tomber QET et en faire un fork. Oui, pourquoi pas 
.
En fait, ce sera pas vraiment un fork, vu que la branche principale de développement s'achèvera quand la nouvelle commencera.
Il s'agit simplement de ne plus assurer de rétro-compatibilité.
Personnellement, je suis plutôt pour car il manque à QET certaines choses primordiales qui n'ont pas été pensées à la base.
De mon point de vue, le fait que les bornes de connexion (les barres rouges et bleues) n'aient pas un ou plusieurs champs texte qui leur soit attaché représente une grosse lacune de conception.
Cela revient à dire que QET ne sera jamais capable de dire sur quelle borne d'un appareil est relié tel ou tel conducteur.
Cette fonctionnalité, c'est la base nécessaire à beaucoup d'édition de post-traitement, comme par exemple :
- les borniers automatiques complets (ceux de Unalcalde ne sont pas complets mais il a tiré le maximum de ce qu'on pouvait faire dans l'état actuel des choses).
- les listes de câble
- les plans/listes de filerie
- etc.
Evidemment, c'est une grosse décision de stopper la rétro-compatibilité.
Mais franchement, pour moi, elle a déjà cessée entre la 0.61 et la 0.7.
Récemment j'ai du retrevailler le plus gros projet que j'ai fait avec QET jusqu'à maintenant. Environ 150 folios créés avec la v0.5-dev de l'époque.
J'ai essayé de la passer en v0.7-dev pour pouvoir profiter des derniéres fonctionnalités et notamment le chercher/remplacer très pratique dans les gros projets. Et ben j'ai failli m'arracher les cheveux quand j'ai réalisé le travail que je devais accomplir pour upgrader tout le projet à la v0.7-dev. Donc je me suis contenter de sortir l'appimage v0.61, d'ouvrir le projet et de réaliser les modifications pour lesquelles mon client me paye.
Ce projet ne sera donc vraisemblablement jamais édité avec une version supérieure à la v0.61.
Evidemment, si ce projet ne faisait que 15 folios, ce serait assez rapide de l'upgrader, mais là, 150 folios, personne ne paiera le travail nécessaire.
Petite anecdote pour éventuellement modérer la dureté de l'évolution possible de QET :
en 1984, Eplan 5 sort sur plate-forme MS-DOS.
Quelques années plus tard, suivant l'évolution des systèmes d'exploitation, Eplan 5 est adapté à Windows et devient, déjà à l'époque, une référence dans son domaine.
Les années passent, le logiciel évolue et est toujours rétro-compatible : on peut toujours ouvrir un ancien projet avec une nouvelle version du logiciel.
Début des années 2000, Windows 7 va bientôt devenir le nouveau standard et Eplan 5 commence à faire viellot dans tous les domaines : performances, graphismes, utilisation, étendu des fonctionnalités, ergonomie... Bref, ce logiciel de plus de 20 ans, qui trimballe toujours sa base MS-DOS sous le capot, doit être remplacé sinon il mourra.
Son remplacant arrive en 2006 et s'appelle Eplan P8. Totalement nouveau (partant d'une page vierge) et utilisant le .NET framework de Microsoft, Eplan P8 est complètement dans l'air du temps et utilise déjà nombres d'améliorations déjà inclues dans QET ou intuitivement souhaitées par Joshua, comme par exemple :
- stockage de quasiment toutes les informations en format XML
- utilisation de base de données pour gérer, entre autre, les articles
- un projet est une archive comprimée contenant toutes les données nécessaires (projet en xml, images, extraits de bdd...)
Malgré tous les chamboulements et améliorations, il est toujours possible de convertir un projet Eplan 5 créé par exemple en 1988 au nouveau format d'Eplan P8 version 2018. Grosso-modo, 30 ans de rétro-compatibilité. Pas mal !
Mais... et il fallait que cela arrive, avec la publication d'Eplan P8 version 2.8 en 2018, la maison-mère arrête officiellement le support et la conversion des projets de l'époque Eplan 5 (1984-2006).
Ce qui signifie que le vieux format devient un gros boulet qui freine voire empèche de nouvelles fonctionnalités (ou mêmes des simplifications qui seraient bienvenues) de voir le jour. Il est donc purement et simplement abandonner après 12 ans pendant lesquelles les utilisateurs avaient la possibilité d'upgrader leurs anciens plans.
Voilà... Il aura fallu 12 ans à QET pour apprendre de ses erreurs de jeunesse. Entre les premières lignes de code de Xavier-l'étudiant-en-informatique aux fonctionnalités pro écrites par Joshua-l'électricien-de-maintenance-qui-maîtrise-bientôt-Qt... Sans compter tous les hacks et améliorations réalisées par Laurent.
Aujourd'hui on en est là et je trouve très bien que Joshua pose ouvertement la question :
faut-il rester éternellement retro-compatible ou non ?
Le prix !!!
.
.
.