Hello, @nbessic2c The release policy is quite clear and explained in the community guide: * Stable version only gets bugfixes (trying to never change the API, whenever it's possible) * A major version (based on trunk) is released once a year, with improvements. We follow this release policy, and no improvements have been made in stable versions in 4.2 or 5.0.
Sometimes bugfixes requires that we change the API. We try to avoid this whenever it's possible. If it's not possible, the change (in trunk or stable) is reported here: The report engine was the only big change applied in v5.0.X. We think is was a big bug (and not an improvement), avoiding to print reports with more than 40 pages (means: unuseable in production). As this change required a major refactor of the whole engine, we: * Made a complete communication to all partners and the community one month before, explaining the changes and what should be changed in custom reports. At this time, everyone agreed on the change (at least, C2C did not said they did not agreed on the change) * Redeveloped the new engine by trying to keep it compatible with the old one, by testing all reports from quality certified modules. The change you complain about (expr attribute) was not used in any official module of Open ERP. I don't even knew this attribute existed on reports. So, sorry if we missed this one, but the report engine rewrite was very important for the stability of Open ERP. @sraps The quality certification is a way for us to guarantee modules'quality in the long term. Each time we release a new version, we check all quality certified modules and update/maintain them if needed. It allows the community to know which module is surely maintained (official ones) and which is probably. (community one) @nbessic2c > The certification will not ensure that the module will work between two minor > or major release Of course, nobody is perfect, and we can also have bugs in certified modules. But if there are some, we fix them asap. The Editions (maintenance contract) guarantee automated migrations between two versions (minor or major). The editions rely on quality certified modules. @nbessic2c > By certifying a module you partially loose the ownership of the module in > favor of > Tiny. Then you are not free to orient this module the way you wants. Not at all. You, of course, keep the copyright on your own module. The quality certification means we will maintain an "Official" version of your module, on which we will do maintenance (guarantee of bugfixes and migrations). This official version will be freezed and will not accept improvements in stable versions. (we apply the release policy on all quality certified modules). But you can always keep your own version of your module (in your own branch or extra/community-addons one). So, you don't loose anything. And, at each new version, you can merge improvements or bugfixes from the official version to your own one. So you easily benefits for bugfixes on this module. On each major new version (trunk), you can propose for merging the improvements you made on your fork. If you want that others companies (or the community) use your own module or develop new module that depends on your own module, you have to provide some guarantee: bugfix and migrations in the long term, never apply changes on the stable version, the code is clean and follow the Open ERP guidelines, ... The quality certification is a way to provide this. > I'm working with OpenERP since version 3 when it was still TinyERP and this > release > aspect has never really evolve till then. Each migration has always been a > pain. With the Editions, migrations are now totally automated for all quality certified modules, since V4.2. In my opinion, it's already a big improvement. > Second point tiny allows certification of modules that does not provide unit > test set. Quality is a priority for us. Quality is complex to manage, we had to set up processes, in depth training to main developers, automated tests, ... Here is what we set up during the past months: * A quality module tester: see the base_module_quality module. It automates the testing of the modules and the check of his quality (availability of demo data, security rules, clean code, scalability of operations, workflow completion, ...) * An integration server (still in development): http://79.125.56.232:8010/ * Automated build/migration & quality check at each commit (still in development): http://79.125.56.232:8010/waterfall?builder=trunkOfficial&builder=trunkExtraAddons&builder=trunkCommunity * A clean communication to organise the community and explain how to work (it includes a big improvement in the guidelines in the community documentation): http://openerp.tv/display.php?rnd=NTM= * A way to track API changes (see bellow) * A clean online documentation on modules * A quality team with double checks on every commit * The editions and module's quality certification Of course, they are more improvement to be done and we continue working on this. We will release the new test server and policies within about 2 weeks. @filsys Last friday, we discovered a major SECURITY hole in Open ERP. (thanks to XRG) This bug requested a very quick new release that have been done friday evening. I strongly suggest everyone to migrate to this new version as soon as possible. We did not had the time to do the communication but we will do it on monday. All Odoo.com customers have already been migrated to v5.0.4. -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=42295#42295 -------------------- m2f -------------------- _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
