Hier j'avais préparé un beau billet. Il parlait du retard pris par le développement de Drupal 7, du rendez-vous raté de Copenhague, renvoyait au graphique dans lequel apparait le mois de novembre comme échéance probable, revenait sur ma question du début du mois sur l'utilisabilité de Drupal 7 avant Noël en (se) disant que cette boutade n'était peut-être plus si loufoque que cela, mais n'osait tout de même pas imaginer que Drupal 7, annoncé de longue date comme LA révolution de 2010, puisse ne sortir qu'en 2011.
Ensuite il revenait sur une idée, que j'avais vue développée dans un article publié peu après la DrupalCon, suivant laquelle une solution à ce retard consisterait à proposer une version 7.0 stable sans le chemin de mise à jour (c'est-à-dire le script qui permet en principe de basculer un site de Drupal 6 en Drupal 7).
Drupal 7, expliquait cet article, est en réalité quasiment prêt, au point même que certains projets sortent déjà en production en s'appuyant dessus : par exemple Dries a cité pendant la DrupalCon le site Examiner.com (qui certes présente un aspect achevé, mais naturellement de nombreuses fonctionnalités n'y sont pas implémentées puisque les modules correspondants ne sont pas prêts). Beaucoup de projets en phase initiale sont aujourd'hui confrontés à la question du choix de la version, et la réponse n'est pas évidente. L'article constatait qu'une part importante des bugs qui retardent la sortie de Drupal 7 viennent en fait du chemin de mise à jour. Donc, disait-il, sortons Drupal 7.0 stable pour permettre aux gens de commencer à l'utiliser sur les projets neufs, et prévoyons de sortir le chemin de mise à jour dans une version mineure suivante. En clair les sites tournant sous Drupal 6 attendraient cette version mineure suivante pour envisager de tourner casaque.
Après avoir expliqué à mes futurs lecteurs que j'ignorais la portée de cette idée auprès des têtes pensantes du développement de Drupal, j'en proposais une petite analyse en disant que certes, cette solution permettrait de fournir Drupal 7 plus rapidement ; mais, ajoutais-je finement, elle entérinerait une sorte de schisme, en coupant, certes symboliquement, certes temporairement, le lien organique entre deux versions majeures de Drupal. En d'autres termes, continuais-je, elle consacrerait, au moins moralement, l'idée que D6 et D7 sont en fait deux logiciels différents. Ce qui n'est pas loin d'être le cas, du point de vue technique.
Là prenait place un intéressant développement sur la "violence" des évolutions entre versions majeures de Drupal. Je rappelais la belle assurance de Damien [qui me charge de vous dire qu'il est bien rentré, merci pour lui] qui jugeait récemment (dans une discussion sur les forums de drupalfr) qu'en fait, Drupal était trop stable d'une version mineure à l'autre, et que ces changements brutaux étaient le meilleur moyen pour faire évoluer Drupal. Comme je lui répondais alors [toujours dans cette discussion, suivez un peu !] que des évolutions "soft, un peu tout le temps" me paraissaient plus facile à gérer que des grosses révolutions tous les 2 ou 3 ans, il affirmait que cette dernière option était pourtant moins coûteuse pour les utilisateurs.
J'en étais à ce stade de la rédaction de mon billet, pataugeant un peu (la fatigue venant) pour exprimer clairement mon scepticisme en essayant d'anticiper le "ça fait 9 ans qu'on fonctionne comme ça, les arguments sur la non compatibilité des versions majeures on les a déjà tous entendus, et on a quand même toujours continué comme ça parce qu'on est convaincus que c'est mieux" par une remarque sur l'extension considérable de l'emprise de Drupal sur le marché ces dernières années - extension qui entraîne à mon sens quelques responsabilités dont on pouvait autrefois se permettre de se dispenser - et sur le fait que tous ces clients n'avaient peut-être pas prévu de changer de logiciel tous les 3 ans [rappelons que je venais de dire qu'un Drupal 7 sans chemin de mise à jour serait assimilable à un logiciel différent], j'en étais là donc quand d'autres nécessités (stomacales) m'appelèrent ailleurs (dans la cuisine), me convainquant d'interrompre mon travail et de finir enfin cette phrase interminable pour laisser mes lecteurs respirer.
J'ai l'immense regret de vous annoncer que vous ne lirez jamais ce billet. En effet, un tweet de Dries ce matin en a rendu nulle et non avenue ma remarque sur la coupure entre D6 et D7, je cite "Newsflash: @webchick and I decided to do another #Drupal 7 alpha release instead of a beta; more work on upgrade path issues necessary".
Deux enseignements à tirer de cette information : d'abord, elle confirme que le chemin de mise à jour est un peu le boulet du schmilblick. (J'ai envie de dire : "ça vous apprendra à révolutionner le monde"). Ensuite, elle confirme l'intuition que j'avais eue de dire que sortir Drupal 7.0 sans chemin de mise à jour serait une décision symboliquement très lourde. Pour autant qu'on puisse en juger, elle serait trop lourde aux yeux du créateur de la Bête, qui parait l'avoir exclue. Au risque de prolonger le retard et de reculer encore l'échéance, peut-être bien au delà de Noël.
Avoir eu raison mais être la seule à le savoir, c'est une sensation terrible. Je vais aller regarder Des racines et des ailes, avec des belles images virtuelles de Cluny reconstitué, pour me consoler.
Et pourtant je l'ai lu :c)
Bonsoir Marie-Hélène,
désolé de te contredire en plein "Des racines et des ailes" mais... je n'ai pas pu m'empêcher de lire ton billet :cP
S'affranchir du "upgrade path" ? En voilà une idée qu'elle me plait !
A noter néanmoins que, à l'heure où j'écris, parmi les 18 "critical bugs" qui paralysent encore Drupal 7, seuls 5 relèvent du "upgrade path".
Et qu'il reste d'autres critères (documentation et accessibilité notamment) qui font partie du "cahier des charges" des incontournables.
Laurent Ajdnik (Drupal Lyon)
Le point "positif" du retard
Le point "positif" du retard de D7, c'est l'allongement de la durée de vie de D6 et ça je ne vais pas m'en plaindre même si je suis tout de même assez impatient!
Par ailleurs, c'est bien joli de mettre les anomalies concernant la migration D6->D7 au niveau critique, mais le problème de la migration se joue aussi au niveau des modules et là:
1° rien n'assure qu'une nouvelle version de tous les modules utilisés pour un site soit disponible pour D7
2° rien n'assure que la nouvelle version du module par D7 soit compatible avec celle de D6 et/ou qu'un processus de migration soit prévu
Donc au final, j'aurais aussi effectivement militer pour 1 sortie de D7 sans procédure de migration. (sachant que la sortie de D7 va certainement provoquer un nouvel élan d'enthousiasme parmi les dév pour les modules qui ne possèdent pas encore de version pour D7)
Salut à tous les deux ! Oui,
Salut à tous les deux !
Oui, vous avez raison l'un et l'autre : le core stable lui-même n'est pas tout Drupal et il y a plein de chantiers encore, comme la documentation. S'agissant des modules communautaires, ta remarque est bonne montesq, le point est d'ailleurs soulevé dans l'article que j'ai cité : malgré le "serment D7CX", beaucoup de développeurs, voyant que D7 n'est pas près de sortir, repoussent en fait le moment de s'y mettre eux-mêmes. Normalement, ils doivent fournir une passerelle entre la version D6 et la version D7 de leur module ; mais, comme je le disais en mai, le travail est (apparemment) considérable pour les gros modules. Tout est assez incertain.
Pour le moment, Dries et Angie s'en tiennent au projet de ne sortir de beta que lorsque le chemin de mise à jour sera prêt, mais la suite des événements leur fera peut-être reconsidérer leur planning.
Ayant eu à faire tourner un
Ayant eu à faire tourner un site encore bloqué sous Drupal 5 pour cause de non disponibilité en version "stable" de quelques modules 'critiques' pour son usage (module 'image' pour n'en citer qu'un), ce retard est loin de m'effrayer ;-)
De même, j'ai l'habitude de n'envisager un saut de version majeure pour un site de production demandant un minimum de stabilité qu'après la publication de la première mise à jour mineure de cette nouvelle version. La fameux principe de laisser à d'autres le soin d'essuyer les plâtres... Visiblement il y a encore quelques mois avant la 7.1, sans compter la disponibilité d'un vivier suffisant de modules complémentaires en version 7. Entre temps, les serveurs tests/dev sont là pour frétiller à la découverte des nouvelles fonctionnalités et préparation de l'avenir.
laisser les autres essuyer
laisser les autres essuyer les plâtres, c'est un sage principe :-)
les modules qui restent éternellement en version instable, c'est aussi un vrai problème. voir cet article que j'avais relevé dans ma veille il y a quelques mois.
bonne soirée !
Poster un nouveau commentaire