I don't understand. You say "If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic"
Every experimented developper know that this argument is the best argument to ask to have more release than 2 per year. And you ask less. So why using an argue to ask more release: The more is the delay between 2 versions, the more is the bug rate on production (that's why more and more project are increasing the release frequency) and difficulty to have a stable version is an exponential of the number of feature added or modified. So your argue is just incomprehensible. I used on production each version, as soon as it is release and announced and I have no problem. Also the stability of a version depends on bugs fixes during the beta period and number of unit tests added when added new future. Developers must work on this direction instead of an "against productive" idea. 2016-10-19 21:34 GMT+02:00 Charles Benke <charles...@benke.fr>: > OK > > > > If I follow your argumentation … I will deliver a brand new version of all > my modules each week, because I have decide to planned like this > > Even if the version is not enough tested, even the previous release have > some know bug, even if the document are not upgraded … > > And I will explain to my disgruntled customers that this is a good method > to make a better quality and simplify their upgrade ... > > > > Release a version every 6 months because FOR YOU is more simple is not > acceptable. I do not develop modules dolibarr because it is easy but > because it allows users to better manage their company, create growth, the > emploies ... > > > > If the major release issued every 6 months was free of bug, stable and did > not require another install/update after barely one month to correct the > most glaring bugs that will not be dramatic > > > > The minimum straightforwardness that we can have with users downloading a > new major release is to explain that this version DO NOT BE USED IN > PRODUCTION. > > > > > > Bien cordialement, > > Charlie Benke > > > > *De :* Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr= > benke...@nongnu.org] *De la part de* Laurent Destailleur (aka Eldy) > *Envoyé :* mercredi 19 octobre 2016 17:34 > *À :* Posts about Dolibarr ERP & CRM development and coding < > dolibarr-dev@nongnu.org> > *Objet :* Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1 > > > > Your argue is not coherent. > > You say you want less version so you have to test your module less often. > It also meas your customer upgrade version less often. > > > > So why just don't you make your tests every 2 versions. Result will be > same. You will work only every 1 year instead of every 6 month, and your > customer would be able to upgrade only every 1 year (once your module is > validated for the version) instead of every 6 month. > > > > It's just your choice and the choice of your customer. > > > > Having a release every 1 year, means nor integrator, nor users have > choice. Also it means a lower quality and exponentiel work to make upgrade. > > But if you prefer to upgrade your module once per year, just do it. You > can, it's just a choice you must do. It is not because there is a new > version, that you must upgrade your module. If you prefer to follow a 1 > year release, just follow this rythm and ask you customer to follow also > this rythm. The only difference is that the ryhtm is defined by you instead > of being imposed be a dolibarr low release rythm. > > And i think it is better to let integrator to decide their release/upgrade > frequency then having this decied/forced by Dolibarr. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2016-10-19 16:49 GMT+02:00 Charles Benke <charles...@benke.fr>: > > Actually I maintain 22 modules, some are simple, some are complex. To test > all of them correctly (use all feature, modify doc, …) each time a new > major version of Dolibarr is release is more than 2 full weeks long for > Romain an me... > > During the month a new version comes out, sales of modules on dolistore > are halved cut (according to my information it is not related to my modules > only). > > > > I could do as some others … , just change the version number and wait for > my clients put bugs me but I do not find it honest > > > > Most integrators with whom I work no longer wish to upgrade versions as > there are no major advances between two versions either-called major > > The final version of each major costs money and energy to NOTHING: just to > show that development teams are able to release two versions per year, two > versions full of vacuum . > > > > We have all been waiting for new accountancy module for 2 years. The time > spent to release a new version will have better been employed to work on > this strategic module… > > > > > > Bien cordialement, > > Charlie Benke > > > > *De :* Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr= > benke...@nongnu.org] *De la part de* Developpement | Open-DSI > *Envoyé :* mercredi 19 octobre 2016 16:24 > *À :* Posts about Dolibarr ERP & CRM development and coding < > dolibarr-dev@nongnu.org> > *Cc :* dolibarr-associat...@nongnu.org > *Objet :* Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1 > > > > Hi > > Thanks to Camille for pointing the main problem : Module and ratio time > spend / bug / patch > As integrator of Dolibarr, it's not "sustainable" for me to test every six > month Dolibarr and the modules I'm commonly using. Today I only install > 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what > functions will be added or remaining experimental. > Modules are too often broken by new version. On the Dolistore you can see > module labeled 3.x-4.0 who are in fact broken with the last version or > doesn't exist for the current version of Dolibarr. I think it's not good > for the reputation of Dolibarr. > I'll be pleased to discuss about this subject in Valence :-) > > Regards > Philippe Scoffoni - Open-DSI > > > > > Le 19/10/2016 à 15:14, cam.la...@azerttyu.net a écrit : > > Hi > > > > Thanks for sharing this. > > I agree, Dolibarr migration is pretty nice ! > > > > but only core part, modules looks more problematic to update. > > > > Regarding communication, this is a work in progress. > > > > Yes I saw this :) But looks again difficult. But it's better :) > > > > From now on, we'll have systematic annoucement when a major version is > released, minor version too, why not. A communication group has been > started within the fundation with the goal to better communicate with the > community. We already are present on social medias, but this dev > mailing-list and the dolistore customers are 2 audiences we poorly > communicate with (not to say not at all). > > > > I don't understand logic, dolibarr users/community are on forum, > mailinglist but piority is social network, strange > > > > About your concerns around PRs and plugins, I'm sorry you feel that way. > PRs are usually correctly integrated and not lost. > > > > Maybe now, I'll try again. But I'm not sure. My fear is to lost again > energy to nothing. > > > > Plugins are the responsibility of their developers. Personnaly, our > plugins are upgraded with the new releases > > > > I'm not module developper then I don't know if is complicate or not to > follow release and provide. As user, i prefer to have my own script and > don't use module. In my use case ratio time spend / bug / patch is too > heavy. > > Thanks a lot > > > > km > > > > _______________________________________________ > > Dolibarr-dev mailing list > > Dolibarr-dev@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > > > -- > > EMail: e...@destailleur.fr > > Web: http://www.destailleur.fr > > ------------------------------------------------------------ > ------------------------ > > Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/ > Facebook: https://www.facebook.com/Destailleur.Laurent > > Twitter: http://www.twitter.com/eldy10 > > ------------------------------------------------------------ > ------------------------ > > * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for > Dolibarr project via Paypal: cont...@destailleur.fr) > > * AWStats (Author) : http://awstats.sourceforge.net (make a donation for > AWStats project via Paypal: cont...@destailleur.fr) > > * AWBot (Author) : http://awbot.sourceforge.net > > * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net > > > > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- EMail: e...@destailleur.fr Web: http://www.destailleur.fr ------------------------------------------------------------------------------------ Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/ Facebook: https://www.facebook.com/Destailleur.Laurent Twitter: http://www.twitter.com/eldy10 ------------------------------------------------------------------------------------ * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: cont...@destailleur.fr) * AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: cont...@destailleur.fr) * AWBot (Author) : http://awbot.sourceforge.net * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
