Bonjour, Le 16.05.2009 01:17, Henri Boyet a écrit : > Bonjour, >> ... >>> Quelle est la prochaine version à tester ? J'ai trouvé une DEV300_m47, >>> mais je ne sais pas de quoi il s'agit ! Est-elle dangereuse ? C'est >>> quand même paradoxal : pour trouver des bugs, il faut passer du temps >>> avec des "vrais" fichiers mais pour être prudent il ne faut pas >>> utiliser des fichiers importants ! >>> >> La version de développement Dev300_m48 est en train de se propager sur >> les miroirs. Comme indiqué dans le bulletin d'annonce cette version >> préfigure la 3.2 qui doit être publiée en fin d'année. >> Il n'y a pas encore de version de développement pour la 3.1.1. >> > Comme il est souvent difficile de faire cohabiter plusieurs versions, > qu'est-ce qui est le mieux ? Tester la future 3.2 ou attendre pour > tester la future 3.1.1 ? Je ne sais pas encore comment vont se faire les tests informels de la 3.1.1. C'est à dire que je ne sais pas si nous allons avoir une version "OOo-Dev" pour la branche 3.1.1 et une autre pour la branche 3.2 auquel cas il sera difficile de les tester ensemble sur la même machine (2 applis de même nom ça ne marche pas). En attendant d'en savoir plus je vais pour ma part installer la OOO300_m48 pour commencer à tester la future 3.2 quitte à l'enlever dans quelques temps pour passer à la 3.1.1. >> Pour moi il n'y a pas de paradoxe : il faut utiliser des vrais fichiers >> importants mais pour ne pas travailler en production et prendre les >> précautions d'usage, il suffit de ne pas utiliser leur version originale >> mais seulement des copies. >> > Ce que je voulais dire, c'est qu'on n'a pas forcément assez de temps > pour utiliser les "vrais" fichiers d'une part pour son travail et > d'autre part pour tester les nouvelles versions. Bien sûr, j'ai des > copies (et même en triple : après deux crashes de disques durs, on > devient parano !) et donc pas de problème si le fichier est perdu en > cours de travail. C'est pourquoi, je travaille dès que possible avec > les versions tests et jusqu'à présent, je n'ai jamais eu à le > regretter. Là où ça me fait peur, c'est de prendre conscience qu'un > fichier peut être altéré de façon invisible : au bout d'un certain > temps, toutes les copies de sauvegarde sont remplacées par le fichier > corrompu ! Même si le risque est très faible et sans conséquence > dramatique pour moi, ça peut être plus grave pour d'autres et donc > freiner les tests sur le vrai matériau. Tu as raison. Ce fichu bug 101690 montre qu'il faut isoler les tests faits sur de vrais fichiers, c'est à dire ne pas réinjecter les fichiers ainsi modifiés dans le circuit normal de production sans être bien certain de leur intégrité. Mais pour cela il faut avoir le temps et les moyens de faire les choses en double, avec la version stable et avec la version de développement. Mais comme les versions stables peuvent avoir des défauts inconnus il est aussi utile de prévoir dans la conception même de ces documents (surtout tableurs), dans la mesure du possible, des moyens de contrôle de cohérence. C'est en cherchant à vérifier l'efficacité d'un tel moyen sur mon propre fichier que j'ai trouvé le contournement que j'ai exposé hier et qui fonctionne apparemment bien dans le cas qui m'intéresse. Je pense que cette notion de contrôle de cohérence d'un tableur est utile de façon générale, même indépendamment de la prévention des bugs de OOo.
Bonne journée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. --------------------------------------------------------------------- To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org For additional commands, e-mail: qa-test-h...@fr.openoffice.org
