Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 2.2.3
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~
Vos question remarques ici sur cette/ces versions
La sortie a été peut être un peu trop rapide :/ une
2.2.3.1 pointerai
correction de classes/internal/class.CMS_Content_Block.php
Comme il faut toujours attendre le contre-ordre avant d'exécuter un ordre, il faut toujours attendre le correctif avant de mettre à jour ses sites :p
Citation :La sortie a été peut être un peu trop rapide
oui une
version corrigée
et je note sue le forum EN
Citation :Thanks to Tomek and JoMorg for testing
Alors super pour Tomek (Ouik), mais pour JoMorg (Fernando Morgado) qui fait partie de la
TEAM c'est
avant de faire sortir la version 2.2.3 qu'il fallait réagir (idem pour l’ensemble de la TEAM aussi)
Pour info, j'ai testé avant la sortie aussi, mais on ne peut pas forcément tout tester. En l'occurrence, il fallait avoir un bloc de contenu avant le block par défaut dans un gabarit, et faire une action de type post (une recherche, ou avec FEU)… Facile à trouver une fois qu'on sait, mais avant pas des masses.
Sans beta publique ou beta réservée à un panel de quelques centaines de testeurs, ce correctif est un moindre mal.
Encore une fois, à défaut de nightly builds, une beta bi-mensuelle mise à dispo des seuls forumeurs permettrait sans doute des tests plus poussés. Je suppose que l'organisation très pyramidale de la team developpement n'y engage guère.
On pourrait pourtant répartir les taches... Un collège d'une vingtaine de membres désignés des différents forums pourrait vérifier/ valider les bugs retournés vers le développeur principal. Cela lui éviterait un afflux considérable de faux bugs et permettrait un développement plus...serein
Citation :Pour info, j'ai testé avant la sortie aussi, mais on ne peut pas forcément tout tester
Je suis en partie d'accord mais et mais
et je suis passé par là mais quand il y a un bug de trouvé ... on passe pour un em....
si tu suis le SVN (et les testeurs de la TEAM Devraient ... mais ) tu verras que
le développeur fait des modifications et c'est la que le problème se situe - pas de contrôle sur les modifications et UN seul dev.
enfin c'est plus mon soucis
jce76350 a écrit :Citation :Pour info, j'ai testé avant la sortie aussi, mais on ne peut pas forcément tout tester
Je suis en partie d'accord mais et mais
et je suis passé par là mais quand il y a un bug de trouvé ... on passe pour un em....
si tu suis le SVN (et les testeurs de la TEAM Devraient ... mais ) tu verras que le développeur fait des modifications et c'est la que le problème se situe - pas de contrôle sur les modifications et UN seul dev.
Oui, je suis le SVN, mais après je ne suis pas suffisamment compétent en php pour dire, tiens il faut que je teste ceci ou cela pour être sûr que ça fonctionne comme attendu.
Par contre, je suis d'accord qu'il ne faudrait pas qu'un développeur pour le core, et aussi mettre en place des procédures de tests (automatiques et manuels) bien cadrées. Je vais voir s'il est possible de faire avancer ça…
Un seul développeur pour un outil comme CMSMS (factuellement c'est le cas, suffit de jeter un oeil au SVN) ce n'est clairement pas une situation idéale.
Il suffit de jeter un œil au nombre de téléchargement des modules les plus populaires en fonction des périodes pour voir où se dirige le navire... (comparer par exemple 2011/2012 et 2016/2017).
La dev Team s'en accommode fort bien, après tout, l'avis des utilisateurs finaux hein....
Discussion fermée cause 2.2.4