A Dilluns, 31 d'agost de 2009, [email protected] va escriure: > I don't really get it, what would that change for you? If your project is > longer than 6 months (this is not always the case for OpenERP I think, I've > seen many SMB's projects been in production in 4/5 months), then you would > simply not update your customer to the very last release if he doesn't want > to pay for it, just like you don't upgrade everyday now (at least once it's > in production).
If I don't upgrade the customer then I have to either give support for more versions or force them to upgrade. For example, Spanish localization modules will usually support fiscal changes with latest versions only. Having more versions is also troublesome and requires more resources, while we're saying we _lack_ resources. > On the contrary, if I think that say the XML/RPC fault code handling really > doesn't fit for my customer (example seen at Smile), then I can allocate > some hours to fix it and I can start working on next release because I know > that my efforts are not worthless because a new version will be there when > I'll need it. I mean, with all partners ready to get their hand dirty and > move the ERP forward, you could easily have like 3 times more skilled > resources on OpenERP for the same cost for Tiny. That's why I insist I see > that as a good solution both to move things forward and also to avoid doing > to much dirty things in a "stable" branch. > > Also bare in mind that if the released twice more often, then > - a lot more people would be early adopters of the next version, thus > testing it much more before there are too many regressions (while now I > know a lot of partners who wait deliberately something like 3 months after > the next release others debug it before jumping in) - difference from one > version to an other would be much smaller. Meaning that instead of doing > the migration nightmare from 4.x to 5.x, you would just follow an easier > path, followed by many more people. Given that you're saying you wouldn't upgrade some customers, you'd have to make them jump a couple of versions (or more) sometimes, which would probably pose the same migrations nightmare, I think. > What do you really expect after all, that something that get developed in > the dark with littel resources and used by nobody during one year will be > stable and really good? I don't believe open source works that way. I > rather believe it works only if many skilled third parties manage to > mutualize development costs from one version to an other which is currently > not the case as third party will not be able to use anything important they > enhanced on the platform before next year, which is certainly out of their > customer scope. Given that the problem is the lack of resources I don't think shorter periods between releases will solve that. If there are not enough resources right now, there won't be enough resources to test new releases every half a year. Even more if I want to upgrade all/most customers. etc.. I understand your POV I just guess this idea doesn't solve the problem of lack of resources. > > > Waiting for comments. Best regards. -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
