Hello folks,
just a word to say that I agree 100% with all what @Joel said, and IMHO Camp2Camp is one of the very best real OpenERP partner reference as they jumped in in early 2006 (you crazy folks), survived it and were even pretty successful now. I insist: shorter release cycles really doesn't mean more bug, because as Joel stated it's much easier to delay risky changes all together to the next coming release rather than cheating on the stable branch as you are forced to by customer needs. But since next version is coming a soon enough, more partner can actually test it/fix it BEFORE it's released, so those risky changes are actually tested and this would IMHO rather meam LESS bugs. This also mean more people would put resource developing OpenERP, it actually mean less internal costs for Tiny or a faster progression instead. In my experience, it would rather cost less to do two small migrations (even more if there are tests) rather than a huge one like 4.2 to 5. IMHO, the main reason why 4 to 5 scripts are still not available for the community is NOT a new profit strategy as some accused Tiny of. It's rather that changes were so huge that even Tiny was unable to release the kind of handy migration scripts they were releasing previously at the same costs (thus releasing them for free). And what is the best: 2 small and free migration scripts lot's of people will test and improve or no script at all, and pay Tiny or some partner to see what happens like v4 to v5 migration? BTW, the issue is that customers will hardly be willing to pay the real price of the v4 to v5 migration cost because they can't imagine it's so complex, whereas they might pay (less) for two small and smooth migrations, or more probably, one yearly migration that would consist in two steps for the partner but would, I think, cost less. @sraps: don't be that suspicious, there isn't any dark world behind partners: except training, I think there is no tech information at all partners have the community doesn't have (so yes it's tough but we do it). I agree with you about the API thing: API changes need to be announced (almost OK even if API blog policy not followed, a resource issue I guess) but also planned and discussed. Again, by releasing more often, API changes could be concentrated all together (and explained/tested) at version changes, rather than on 'stable' version is it is the case now. Moreover, currently, even if Tiny would like to delay all API changes they think about to the next yearly version it wouldn't be possible. Why? Because they would have only 2/3 months of heavy resources to put in building the new version (nobody outside helping as they have no incentive in doing so with long release cycles) so they would actually lack resources. And if they do a mistake it will last for one year. Finally they would even forget about the changes that were discussed one year back (I just imagine a huge list of un-classed blueprints with no comment/feedback), just like with the bugs, probably only the last ones would be implemented. Finally I agree with sraps about the fact that unfortunately module API is not so well designed. It would need to change... How to improve it? If you release too slowly it would take lots of years and you might changes API as customer needs arise on stable branches. And for most of the API it would mean that useful refactoring would simply never be done. What are the implications of not doing that API refactoring? Well, IMHO the implication are less module integration (less usability) and MORE bugs. Indeed, improper API design means that module implementers need to cheat the API (just like in for the product configuartor I made at Smile where I had to override ir.actions for instance...) , do things they shouldn't do, copy/paste large portions of code (they would lately received fixes unless in the pasted versions). For instance, if a method is too large, doing lot's of things in the DB and not returning all the IDs it created/changed in DB, then if you override you should do hugly things to UNDO part of what has been done or copy/paste a 150 lines methods that will never receive fixes in your version... It's very important to carry on the refactoring over the time an plan it in order that it doesn't become a cost for all users. Please read that blueprint for details: https://blueprints.launchpad.net/openobject-addons/+spec/code-refactor-for-better-extensibility All right, again v5 is really usable and good by now, it's just unfortunate it took so long to get it bugfree and we all hope next version won't take as long. If it's the case, just because v5 is good enough, then I think lot's of people will delay v5.2/v6 adoption as long as possible in order to avoid being the first kamikazes, meaning that the one that would do the move would suffer even more. For instance, well advised Camp2Camp has been one of the last to move to v5. In one hand they were right cause they avoid crash testing for them, in the other hand we lacked their help. I would rather like we could all help in stabilizing the next versions. Best regards ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=42493#42493 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
