Même si on peut raisonnablement penser que le changement de JRE n'aura pas d'effet (et je suis d'accord), on ne peut pas le garantir sans l'avoir testé. Il y a donc un risque qu'il n'est pas souhaitable de prendre au démarrage d'une campagne. En plus, si le changement de JRE n'apporte rien au logiciel, il est inutile de prendre ce risque. A moins Tony que tu me dises que de ton côté c'est la JRE 1.7.72 que vous utilisé pour vos tests depuis plusieurs versions et dans ces cas là on limite beaucoup la prise de risque. Sinon j'ai retrouvé, on était en 1.7.55 avant. J'ai une proposition qui peut limiter ce risque avec une solution de contournement en cas de problème : - on reste avec la 1.7.72 - on prépare un répertoire avec la version 1.7.55 de la JRE En cas de problème lors de la campagne, on leur demande de remettre l'ancienne JRE (juste un répertoire à recopier). Tony, si tu peux juste me confirmer que la mise à jour de la JRE ne fait rien d'autre que de mettre à jour ce répertoire. Les seuls problèmes qui pourraient restés sont : - le cas d'un bug lié à la JRE qui ne serait pas visible durant la campagne et dont on se rendrait compte après - le cas d'un bug rencontré qui ne serait pas lié à la JRE et donc on ferait le changement pour rien (mais on s'en rendra compte car on aura toujours le bug) Si on reste sur la version 1.7.72 durant IBTS, on aura validé le bon fonctionnement d'Allegro Campagne après IBTS... Vincent, je te prépare le répertoire pour la JRE 1.7.55. Christian Le 08/01/2015 11:04, Tony Chemit a écrit :
On Thu, 08 Jan 2015 09:53:29 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
ok, donc on va faire marche arrière pour IBTS. Pour moi y'a pas de risque, je ne vois pas l'intérêt de cette discussion.
La question à se poser : est-ce que sur IBTS ils ont déjà installer l'appli ? il me semble que non, Vincent l'installe demain.
Donc ils partent avec la dernière JRE et tout fonctionne bien. Enfin je ne vois que de la complexité à vouloir revenir en arrière.
Tony, tu peux me confirmer la version antérieure ? C'est bien la 1.7.65 (ou la 1.7.67) ? Je n'ai pas de copie de vos fichiers, je ne sais pas.
Question subsidiaire, comment on fait marche arrière sur un poste où la JRE 1.7.72 a déjà été déployée ? On fait pas je pense. C'est automatique, sachant qu'on descend en version ? non il n'y a pas de mécanisme de mécanisme de redescente de version.
Ou il y a une astuce en supprimant le répertoire JRE (mais du coup comment l'appli peut se lancer ?) ? Ou on ne peut pas et il faut réinstaller ? Je pense que le mieux c'est de surout ne rien faire et laisser tel quel.
Merci Le 06/01/2015 17:07, Tony Chemit a écrit :
On Tue, 06 Jan 2015 16:46:32 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
Normalement ça devrait être bon (en plus ce n'est pas un changement majeur) mais c'est vrai qu'il y a toujours un risque. Tony, il y avait un problème nécessitant le changement de version ? Sinon est ce qu'on ne peut pas repousser ça à la prochaine version pour qu'on ait le temps de bien tester ? Ou alors on tente le coup. Je ne vois aucune contre-indications à ne pas le faire, mais si vous préférez attendre ça le fait aussi, ce n'est pas primoridial. Merci
Christian Le 06/01/2015 16:40, Vincent BADTS a écrit :
Bonjour,
J'espère que c'est pas risqué de faire ces mises à jour juste avant une campagne ! Qu'est ce que je dois tester ? A+
Vincent
Le 06/01/2015 16:27, Christian BONNET a écrit :
bonjour, c'est fait (au passage meilleurs voeux). Par contre il faudrait je suppose que tu fasses quelques tests Vincent.
Christian Le 06/01/2015 15:49, Tony Chemit a écrit : > Hello, > > Pourrais-tu mettre aussi à jour le composant jre dans le fichier des mises à jour applicatives : > > jre.version=1.7.72 > linux.i386.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72... > windows.i386.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72... > windows.x86.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72... > #linux.amd64.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72... > #windows.amd64.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72... > > Merci, > > tony. > --
Site Ifremer <http://www.ifremer.fr> Christian BONNET
Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Département Infrastructures Marines et Numériques (IMN) Unité Informatique et Données Marines (IDM) Service Ingénierie des Systèmes d'Information (ISI)
christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
_______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel -- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques)
IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique)
Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38
www.ifremer.fr
-- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Département Infrastructures Marines et Numériques (IMN) Unité Informatique et Données Marines (IDM) Service Ingénierie des Systèmes d'Information (ISI) christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
