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/jre-1.7.72-linux-i586.zip
windows.i386.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72/jre-1.7.72-windows-i586.zip
windows.x86.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72/jre-1.7.72-windows-i586.zip
#linux.amd64.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72/jre-1.7.72-linux-x64.zip
#windows.amd64.jre.url=zip:http://nexus.nuiton.org/nexus/content/repositories/jvm/com/oracle/jre/1.7.72/jre-1.7.72-windows-x64.zip

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
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
www.ifremer.fr

Tel : +33 (0)2.98.22.46.16
Fax : +33 (0)2.98.22.46.44