Sélection par défaut du date picker en erreur

4.0
Sélection par défaut du date picker en erreur
0
Tags: #<Tag:0x00007f64879968d8>

(g thelohan) #1

Bonjour,

Nous constatons depuis peu que pour les mises à jour de datetime, le datepicker sélectionne par défaut une date en 1899 (problème de parsing datetime ?).

datetime

Nous sommes en version:
4.0 patch level P21 (database patch level P21)Built on2018-10-12 18:20

Auriez-vous une explication ?
Merci d’avance,

Guillaume.


(David AZOULAY) #2

Effectivement il y a un pb de sélection de datetime sur la UI responsive P21

Le pb ne se produit pas en P22, ça n’a donc pas sans doute pas dû être correctement backporté / mergé en P21. Nous vous tenons au courant.

Aviez vous détecté ce pb sur la prerelase P21 ? En particulier sur la dernière prerelease “release candidate P21” cf Simplicite platform version 4.0 P21 RELEASE CANDIDATE.


(David AZOULAY) #3

Nous avons re-mergé le code relatif au datetime picker de P22 vers P21. Il ne devrait plus y avoir le pb.

La branche release du template d’instance et les images Docker correspondantes ont été mises à jour. Je ne sais pas quelle est votre procédure d’upgrade mais vous devez donc la réappliquer. Vous serez alors sur:

Version=4.0.P21
BuiltOn=2018-10-15 14:53 (revision a443996de9f9a929f0768a7e10ef0309d0ce6e86)

(g thelohan) #4

Je n’ai pas testé en prerelease ou eu d’info à ce sujet.

Les datetime picker refonctionnent, merci.


(David AZOULAY) #5

Nous avons initié dans le cadre de la P21 un processus de release progressive qui permet de mieux accompagner nos clients et partenaires dans la qualification d’une version avant sa release officielle.

A ce titre nous poussons la P21 sur une branche prerelease depuis de nombreuses semaines, le vendredi 6/9 nous avons poussé une dernière P21 prerelease dite “release candidate” qui, en l’absence de retour négatif, a été poussée telle quelle en release.

Je ne sais pas comment sont vos processus de mise à jour socle mais l’ideal aurait été de la qualifier sur la base de la prerelease (à minima la prerelease “release candidate”), avant d’appliquer la release.


#6

Bonjour David,

je rebondis sur cette discussion afin de déterminer quelle serait la meilleur configuration de nos environnements.

Nous avons 4 environnements différents: test, dev, rec, prod. A mon sens, dev, rec et prod doivent être sur la même branche, de façon à éviter les régressions dans le pipe de développement dev>rec>prod. C’est donc forcément la release.

Test doit nous permettre notamment de tester les corrections de bugs que nous vous aurions remontés, auquel cas il doit être sur le master. Il est aussi utilisé parfois pour continuer les devs en attendant qu’un bug bloquant soit corrigé dans la release. Cependant, on n’a alors pas d’environnement en prerelease!

Bref j’ai un peu de mal à trouver la solution idéale sans multiplier les environnements et passer beaucoup de temps en qualification, ce que malheureusement nous n’avons pas le temps de faire!


(David AZOULAY) #7

En fait il ne faudrait plus que vous utilisiez la branche master (sauf très ponctuellement pour valider qu’une évolution/correction que vous avez demandée vous convient). La branche master est un snapshot de dev (quotidien voire plus) qui peut donc être parfois très instable.

La logique serait donc que vos instances de DEV/TEST soient sur la branche prerelease (pour vos projets en cours) ou sur la branche release (pour vos projets en finalisation et en maintenance) et que vos instances de PROD soient sur la branche release

Nous allons accélérer le rythme, notre objectif est de pousser sur prerelease de manière hebdomadaire et sur release de manière mensuelle ou - au pire - bimensuelle (lors des périodes de congés par exemple)

Désormais, avant chaque release on poussera sur prelealease une “release candidate” qu’on estime prète pour être poussée sur release. On attend de votre part de tester cette “release candidate” sur vos cas particuliers afin d’améliorer la qualité de la future release et de ne pas découvrir des pbs en PROD. Donc, dès l’annonce de cette “release candidate” il faudra basculer temporairement vos instances de DEV/TEST qui étaient calées sur release à prerelease et faire les tests qui vont bien (une fois la "release candidate poussée en release vous devrez rebasculer ces instances sur release)