/mode collaborateur au projet : ON @Voljega, et il me semble que lors de cette "discussion de comptoir" @retroboy a expliqué clairement le raisonnement ayant poussé à prendre cette décision. Ce choix peut très bien ne pas te satisfaire, soit. Mais à un moment donné, il faut voir le problème dans son intégralité. 2 versions d'un même système radicalement différentes en terme de fonctionnement interne, ayant chacun une structure et un mode d'update propre. Cela se traduit par 2 versions à maintenir simultanément en terme de support technique, documentation et infrastructure serveur (et oui, les maj OTA ne tombent pas du ciel... tout comme les builds... il y a de gros serveur privés derrière recalbox, payé chaque mois par @retroboy.) Maintenant qu'est ce qui a bien pu nous passer par la tête pour nous lancer sur le chantier de la 4.0.0, alors que nous avions, en effet une 3.3.0 qui, en apparence, était prête à tourner au poil de cul en versions table?! Et bien sachez que ce n'est pas parce que vous n'avez, personnellement, jamais eu de soucis avec, que tout le monde se trouve dans la même situation. En effet, au cours de la phase de dev de la 3.3.0, nous avons reçu énormément de feedback négatifs concernant le système d'update utilisant rsync ainsi de niquage du FS... Les 2 entraînant simplement la corruption intégrale du système et obligeant une réinstallation complète du système. A ce moment là, nous nous retrouvions alors face à 2 choix : - 1, la facilité : fermer les yeux devant ces soucis, et continuer recalbox avec un système de base en 3.3.x. Nous serions alors parti du principe que ce n'était pas vraiment un souci, étant donné que ces problèmes étaient "relativement" rares... Nous pouvions continuer ainsi et partir du principe que si les utilisateurs devaient refaire une fresh install toutes les X updates et bien soit, chacun sa merde. La 3.3.0 étant alors à 2 doigts de passer en release en stable, cela nous aurait bien arrangé la vie... -2, la sécurité : ouvrir les yeux face à ces soucis et trouver des solutions à ces problèmes. Les solutions étaient connues et devaient à la base être intégrée dans une version lointaine de recalbox étant donné la masse de travail que cela représentait. Mais finalement, après de lonnngues discussions, nous avons décidé d'avancer ces milestones et de bosser sur les nouvelles features comme le passage du système en read-only et la refonte complète du système d'update du système, afin de garantir un plus grande stabilité au système. Le système d'update n'utilisant plus rsync, devenait alors incompatible avec le système mis en place dans les versions antérieurs de recalbox. Nous étions conscient des désagréments utilisateurs que cela engendrerai pour les utilisateurs, notamment pour ceux ayant déjà un installation en 3.3.0 beta (confusion dans les numéros de versions, obligation de repartir sur une fresh install pour passer d'une 3.3.0 à une 4.0.0 etc...) Mais à un moment donné, lorsque l'on voit que l'on fonce droit dans un mur, il faut savoir changer de direction... Après certes, nous aurions très bien pu, continuer sur la branche 3.3.0, et intégrer ces modifications dans une énième beta... Car en fait, la 4.0.0 n'est rien d'autre qu'une 3.3.0 avec un système en read only et un nouveau système d'update + quelques ajouts "mineurs". Mais justement cette "cassure" en terme de fonctionnement interne de l'OS, nous a poussé à changer de branche pour la 4.0.0 , afin de marquer l'impossibilité de migrer d'une 3.3.0 vers une 4.0.0 . Par la même occasion, nous avons mis en place un système à 3 sous-branches (unstable, beta, stable) afin séparer chaque stade de développement d'une même version (et oui nous avons beaucoup appris durant cette période) et permettre facilement à chaque utilisateur de choisir laquelle il souhaite utiliser en modifier une simple ligne dans le recalbox.conf Maintenant, ces choix ne te plaisent peu être pas, mais il fallait prendre des décisions et il faut faire avec. Impossible de satisfaire la totalité des utilisateurs à chaque fois. Nous essayons de raisonner en terme de bénéfices globaux pour l'ENSEMBLE des utilisateurs et le système à chaque prise de décision. /mode modo : ON Je trouve inadmissible la tournure que prend cette discussion. Ce genre de discussion totalement stérile ou chacun vide son sac et ses ressentis à chaud n'apportent rien de bon ou de constructif. Uniquement ambiance pourrie dans la communauté, démotivation de la part des personnes s'investissant dans le projet et une image de projet "kévinkikoolol" à recalbox. Ce n'est malheureusement pas la première fois que cela se produit... Mais si à l'avenir cela se reproduisait, des sanctions devraient alors être prise pour préserver l'ambiance globale du projet... Je clos ce sujet.
