dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Versions et Roadmap Dolibarr


From: Juanjo Menent
Subject: Re: [Dolibarr-dev] Versions et Roadmap Dolibarr
Date: Wed, 15 Dec 2010 11:38:57 +0100

Il est possible que ce que je dis n'a rien à voir avec la discussion de
versions et Roadmap,mais fondamentalement, dans une question de temps: 

Ne pensez vous pas que nous sommes peu nombreux pour un développement à
grande comme c'est Dolibarr? et cela peut influencer le temps de delai
entre chaque release? 

Je pense que nous devons maintenir un équilibre entre le temps de delai,
les fonctionnalités et de la qualité, avec la priorité à la qualité

El mié, 15-12-2010 a las 10:59 +0100, Laurent Destailleur (eldy)
escribió:
> >> Il n'en ont pas obligation. Ne migrer que si il y a besoin. J'en connais
> >> un qui est toujours en 2.6, sic (il se reconnaitra). C'est comme pour
> >> linux ou ubuntu. On upgrade si cela se justifie.
> > oui mais ce se justifie souvent, car des bugs sont corrigé en masse
> > entre les versions et des modules externes ont souvent besoin d'un
> > upgrade pour fonctionner.
> Oui, d'ou le besoin de ne pas mettre un délai trop important entre
> chaque release.
> D'autant que Dolibarr est encore en phase de "suppression des fonctions
> rédibitoires", comme la gestion des stocks limités à l'entreprot 1,
> l'impossibilité de modifier un modeles de facture ans connaissances
> techniques, ou l'absence de champs personnalisé, mais aussi d'autres
> dont un paquet a été mis en 3.0 (comme la possibilité d'inverser adresse
> desti et emetteur pour avoir l'emetteur a droite qui est une obligation
> dans certains pays, ou encore la possibilité d'afficher les id
> entreprise sur les factures, la aussi redibitoire pour certains pays).
> D'ou le rythme de 1 release tous les 6 mois.
> >
> >>> Quant à la suite du travail de modularité, effectivement, de ce dire que 
> >>> la 3 
> >>> part sur la base d'un modularité accrue et fnalisé, me parrait être une 
> >>> bonne 
> >>> approche en terme d'objectif
> >> Oui, c'est bien ce vers quoi on tend à chaque version. Exemple la 2.9
> >> intégrait la séparation des modules externes par repertoire et la 3.0
> >> intègre le canvas.
> > tout ceci est côté développement et totalement transparent pour
> > l'utilisateur lambda, ce dernier il veut du concret dans les
> > fonctionnalités et dans le visuel.
> >
> > beaucoup sont déçu de l'ergonomie par exemple (template ou clic à gogo),
> > et c'est souvent un point crucial chez l'utilisateur final.
> En effet, le RDV avec la CCI a montré que les utilisateurs voulaient
> plus de graphiques (Lundi matin business en a pas mal). Avis donc au dev
> de reporting.
> 
> >
> >
> > Cordialement,
> >
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev





reply via email to

[Prev in Thread] Current Thread [Next in Thread]