Oui tout à fait, une migration est un vrai projet qu’il faut faire avec soin. Pour info, quel est le coût d’une migration SAP ?
Ce n’est pas parce que c’est libre, open source, simple que c’est forcément sans risque.
Trop d’utilisateurs se contentent de remplacer les sources et d’exécuter le script de migration… sans aucun essai, ni test, sans avoir lu le changelog… De l’amateurisme pur.
Actuellement la communauté se donne la peine de maintenir gratuitement et bénévolement la version stable en cours (actuellement 3.8), ainsi que les deux versions précédentes (donc 3.6 et 3.7 actuellement). Donc les utilisateurs bénéficient de corrections sans avoir besoin absolument de migrer vers la dernière version et la laisser « mûrir ».
MAIS il faut quand même tester avant mise en prod, car malgré le soin des développeurs, nul n’est infaillible ni parfait.
Si je peux me risquer a faire un petit retour d’expérience, ds une des sociétés ou j’ai travaillé et ou ils avaient déployé SAP (a l’époque le coût de déploiement s’était chiffré en Millions de francs… pour passer d’un AS 400 sur movex ver sap) merci les consultants ! ;).
Une fois cette version de SAP déployé la moindre tentative d’évolution était bloquée car nous étions sur une version déjà dépassée mais préconisée a l’époque car …on est sur qu’elle marche !!!.. résultats : oui elle marchait (enfin presque) mais si on voulait installer de nouvelle fonctionnalités (web services, etc…) , il fallait migrer la version… résultat coût exorbitant donc on ne bouge pas…
tout ça pour dire que je pense qu’il ne faudrait pas que ca arrive à Dolibarr…
L’idéal serait que tout le monde puisse passer a la version 3.8 puis 3.9 et enfin 4 pour assurer un maximum de cohérence.
Comme on le voit dans les forums, les montées de versions causent souvent des soucis alors ma question de Béotien est la suivante :
Pour les install qui sont antérieures à la version 3.8, serait 'il possible de faire évoluer ces plate formes en ne faisant que reprendre les données de la base ?
En gros, on installe une nouvelle version en 3.8 et on ré importe les données dans la base.
Une version LTS serait vraiment une bonne idée et effectivement, ce serait chouette d’avoir quelques fonctionnalités manquantes. Je plussoie là dessus le post de Maxdevis sur le travail en masse dans tous les éléments dolibarr mais principalement les tiers (affecter en masse dans les catégories, désactiver, cloturer), les propales (cloturer en masse ! passer à facturée en masse etc…)
Le rêve serait que le travail en masse prenne en compte les extrafields. Je sais que c’est jouables avec mylist mais ce n’est pas franchement accessible pour le moment.
Sinon par rapport au paiement de développeur, je suis à 200% pour. Pour moi c’est à l’association de gérer cela. Quitte à instaurer un développement tournant parmi les membres golds qui le souhaitent. en tant qu’association, il doit également être possible d’aller chercher de l’argent. Je pense notamment :
- Au mécénat d’entreprise en faisant un appel à nos clients respectifs
- Aux institutions de la vie associative (Avise ? / FNDVA)
- Aux fondations privées (Free / microsoft, etc…)
- Aux pôles French Tech.
Le numérique a le vent en poupe et l’argent se trouvera par contre cela nécessite que quelqu’un passe du temps (beaucoup) à solliciter cet argent et à monter les dossiers. Est-ce le moment de réfléchir pour l’association à embaucher une personne pour cette mission ?
Oui votre idée est intéressante : il faut réfléchir à des processus de traitement de masse, nécessaires dans certaines situations.
Je ne crois pas que ce soit juste une question de fonds.
Le développement de dolibarr est fait jusqu’à présent de manière communautaire et bénévolement. Les développeurs travaillent de manière indépendante et se financent par les services qu’ils vendent basés sur Dolibarr et non pas par le dev fait pour améilorer ou corriger Dolibarr.
Alors payer un développeur pour du développement Dolibarr va poser des questions : qui ? sur quelle tâche ? qui définit le cahier de charges ? qui va faire les tests ? qui valide ? Comment s’organiser ?
Par contre, rien n’empèche de chercher un développeur pour créer un module et le proposer sur dolistore (et le maintenir, le faire évoluer …)
L’association peut être un lieu où ce genre de choses se discute et s’organise. Notre fonction : faire vivre le projet et la communauté, trouver les moyens pour (je fais partie du CA).
Ce qui est important est de faire remonter les besoins. Un ERP ne serra utile que s’il répond aux besoins de ses utilisateurs.
Le travail en masse est selon moi l’un des principaux manque de dolibarr. Pour travailler très souvent sur wordpress, le travail en masse est vraiment très pratique et génère un gain de temps appréciable.
Au niveau du développement, pourquoi ne pas mettre en place un fonctionnement démocratique ?
- L’association recherche des fonds (via un salarié ?)
- L’association rédige les spécifications (via un salarié ?) quitte à réaliser en amont une enquête auprès des membres
- Elle appelle des propositions de la part de développeur
(Je serais tout à fait satisfait et rassuré que seuls les prefered partner soit eligibles au développement de Dolibarr dans le cadre d’un développement payé par l’association dolibarr)
- les propositions sont rendues publiques aux membres de l’associaiton
- Les membres de l’association ont chacun un droit de vote sur le principe 1 membre = 1 voix
- Le développeur retenu développe
- Les tests sont faits par les membres de l’association et / ou les utilisateurs
- La validation est faite par le CA ou par un groupe de travail dédié (élu par les membres)
Ce ne sont là que des hypothèses, et rien n’empêche en parallèle de poursuivre le développement bénévole et/ou de rémunérer des développeurs pour des nouveaux modules ou des nouveaux besoins.
Un petit message car en allant sur le git, j’ai vu clairement des référence à la version 4.0 et je me pose la question de savoir si la 4.0 sera une ‹ vrai › version majeure ou simplement une 3.10
On ne pourra considérer la prochaine version comme 4.0 il me semble que si celle-ci contient :
la comptabilité
le multidevise
et accessoirement des listes personnalisés natives à la sauce myList
et je rejoins l’avis de Charly @defrance pour l’intégrations des minimas au niveau fonctionnalités. (pour la compta ça semble bien parti avec le projet en cours, mais à voir, je n’ai malheureusement pas eu les moyens d’y participer, donc j’attend ^^)
Si en plus, des bases de gestions d’OF/atelier digne de ce nom pouvait être intégrées… ça serait le paradis!
la remarque de @altatof est censées, comme d’autres demandes sur le forum:
- où se trouve la roadmap ? (roadmap future long terme: pas liste des choses en cours pour la version +1)
- y a t il des réunions organisées pour sa définition ? (virtuelles ? dlicamp 2016 ?)
je parle évidement de définitions de projet fonctionnelles et pas d’environnement de développement collaboratif (git sourceforge ou autres…)
je viens de pousser pour un client une évolution du module resource dans le core https://github.com/Dolibarr/dolibarr/pull/4545
cela devrait me permettre d’affecter une machine ou un atelier à un OF au niveau de factory et à moyen terme d’avoir enfin une vue planning de ceux-ci
A part la date de sortie il n’y a pas à ma connaissance de roadmap fonctionnelle de dolibarr
Je vais poster un message sur la mailing list dev à ce sujet
Mais e reviens donc sur mon idée qu’il doit y avoir une équipe qui bosse sur le réglementaire. un logiciel qui répond « réglementaire » ça rassure !
@+
