Bonjour Charles, >>>Le choix de sorties de version prévues à intervalles réguliers dans le >>>temps (https://wiki.documentfoundation.org/ReleasePlan) est un modèle >>>qui a été voulu dès avant le premier jour du projet LibreOffice. >>>>L'alternative est un modèle de sortie "quand c'est prêt", qui a été en >>>>place un temps (mais pas uniquement) au sein du projet OpenOffice.org… Sans vouloir t'offenser, ceci tient quand même un peu du faux dilemme. Il existe d'autres solutions comme celle qui consiste, après constat d'un éventuel problème récurrent, à faire une pause pour réellement finaliser une version fiable. Dans la page du release plan, je lis : « Note that the dates mentioned in the schedule might get shifted if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate does not fit the Release Criteria. Such problem would shift the final release by one week or even more. »
Après l'épisode mouvementé du tri sous Calc, ce bug est un nouvel exemple de ce que peut causer la nécessité absolue d'avoir à sortir une nouvelle version dans des délais très courts. D'autant plus que lorsque je télécharge le master via SIGUI, j'obtiens une 4.5… soit, trois versions en même temps et non 2. Ce bug est reproductible sous la 4.3 par la simple copie du tableau de la première page dans n'importe quel document sous Word 2013. En affinant un peu, on se rend compte que l'insertion d'une « combobox » dans un tableau dans Word, provoque le problème (voir un crash) à lecture du docx sous Libreoffice. Je n'ai pas MSOffice chez moi pour pousser plus loin les investigations. Quoi qu’il en soit, Une version de Libreoffice à une durée de vie en tant que version stable de l'ordre de 6 mois… Décider à 5 mois de la fin de vie qu'il n'y a pas de nécessité de correction me gêne,… dans la démarche. >>>>- ralentir le rythme des sorties dans le temps: d'accord, mais à quelle >>>>fréquence? Le nombre de bugs diminuera-t'il?… J'en suis convaincu. >>>> N'oublions pas que les bugs >>>>ne sont repérables que parce qu'on teste le logiciel,… La QA à ses limites, et il est vrai que les testeurs sont noyés dans le recommencement incessant des mêmes tests. Car il ne s'agit pas de tester uniquement ce qui ne marchait pas. Il faut tout reprendre à chaque fois. Le test ultime de toute application est son utilisation en production, … avec de vrais utilisateurs. Est-il aberrant d'envisager qu'après avoir déclaré une version (vraiment) stable (qui pourrait être la date de fin de vie actuelle) une période de … 3 mois par exemple, soit consacrée à la remontée des problèmes réels via les forums par exemple… pour finalement donner lieu à une Version finale ? >>>>il y aura toujours une bonne raison pour laquelle la version stable ne sera pas prête... C'est vrai. Mais il y a « pas prête » et « bugguée », ce n'est pas la même chose. L'absence d'une fonctionnalité sera toujours préférable à la présence d'une dysfonctionnalité. Je suis bien conscient de ne pas être en possession de toutes les informations et d'avoir un point de vue d'amateur sur la question, ... mais je m’inquiète un peu quand même pour l'image du produit. Cordialement, Denis -- View this message in context: http://nabble.documentfoundation.org/Rythme-de-sortie-tp4137159p4137375.html Sent from the Discuss mailing list archive at Nabble.com. -- Envoyez un mail à [email protected] pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/discuss/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
