Le 24/08/2011 16:10, Jean Heimburger a écrit :
C'est vrai que c'est à nous de faire des tests.
La dernière stable date de mai 2011, je commence à peine à la
déployer chez des utilisateurs, et elle présente des limitations
assez sérieuses pour de la production. Les utilisateurs finals
n'envisagent pas 2 migrations par an... Pas comme les développeurs
que nous sommes.
2 versions par an c'est trop à mon sens.
Pour l'utilisateur, oui, a lui donc de migrer qu'une fois par an ou
une fois tous les 2 ans si il veut monter plus lentement.
Pour le gestionnaire de projet, compte tenu du nb hyper important
d'evol, 6 mois c'est un peu limite. Le jour ou le projet sera moins
actif, on pourra réduire.
"release early, release often" est l'adage des bons projets opensource !
Et on ne sait jamais ce qui a été modifié, dans quel but, pour
pouvoir tester spécialement ces éléments. Et mettre des modifs qui
sont nécessaires pour une version future, mais qui gènent le
quotidien des utilisateurs présents est difficile à expliquer et
passe mal chez les utilisateurs.
Oui, lui dire d'attendre 2 ans pour avoir une fonction qui viens
d'etre ajouté juste apres une release, c'est long. Voila pourquoi il
faut un rythme un peu plus élévé et des version tres stables.
Ainsi celui qui veut absolument la fonction sans attendre peu l'avoir,
celui qui veut migrer que rarement, il migre rarement.
"qui peu le plus peu le moins"
@+
Jean
Laurent Destailleur (eldy) a écrit :
J'aime quand ca se reveille.
Cela fait 3 mois que la beta a commencé (pres d'un centaine de bug
reportés et corrigé par les testeurs sur dolibarr.org qui testent a
fond).
Donc il est temps de vous y mettre les gars....
Le 22/08/2011 22:00, Jean Heimburger a écrit :
Tout à fait, et je dirais que c'est le moment de tester à fond...
Ca ne sert pas à grnad chose de sortir des versions bancales et
inutilisables en production par de vrais utilisateurs qui ne sont
pas développeurs.
@+
en tous cas pour le futur
http://www.dolibarr.fr/forum/527-bugs-sur-la-version-stable-courante/27997-gestion-des-remises#27997
Régis Houssin a écrit :
Je serais assez d'accord pour qu'on finalise des fonctionnalités
importantes et essentielles pour une entreprise comme les avoirs
(client, fournisseur) et qu'on vérifie a fond le fonctionnement
des modules principaux avant de sortir une version stable.
-----------------------------------------
Régis Houssin
Tél. +33633020797
http://www.dolibarr.fr
http://www.dolibox.fr
Le 22 août 2011 à 21:31, Jean Heimburger
<address@hidden> a écrit :
Suite au mail que j'ai envoyé cet AM concernatn les remises
saisies comme des montnats négétifs sur une commande et qui
deviennent des ligne facturées sur la facture
Juanjo m'a envoyé ce post sur le forum international.
http://www.dolibarr.org/forum/12-howto--help/17770-negative-prices-not-working#18561
Puisque la saisie de remise en négatif ne marche pas en 3.0, j'ai
essayé par la méthode indiquée et je vois que c'est toute la
gestion des remises qui est KO puisque si on créé une remise sur
le client, elle devient une ligne de facture sur la facture.
Je comprends le changement, mais là ça provoque une régression
qui n'auraient pas dû être dans une version stable. Ca donne des
utilisateurs mécontants et nuit à la longue au projet.
J'ai essayé sur la version Beta :
On peut affecter une remise absolue à une commande, mais elle
n'est pmas reportée sur la facture qu'on créée.
De plus on peut affecter la remise deux fois (et plus) sur la
même commande.
Pour moi ce sont des bugs à corriger avant de publier la 3.1
comme stable.
Jean