View source | Discuss this page | Page history | Printable version   

Release Management/Mantis and CI structure with 3.0


Mantis and CI welcomes 3.0


Till now our old infrastructure (repos/mantis/CI) was quite efficient in handling our devel (2.50) and stable (2.40/2.35) branches, but with the introduction of new major version (3.0), they all need some changes to accommodate the new version (3.0). And as we (RM) have already announced the changes we plan to do in our repository structures, now it is time for Mantis and CI (hudson). And this wiki explains the proposed changes for Mantis and CI

Changes in CI

As proposed for the repos, 3.0 will be using the existing repositories (pi, main, try etc) so we are going to have our 2.50 in new repositories under stable branch. So the jobs in hudson will also use the existing jobs/views (try, int etc) and 2.50 will have its own new jobs and views.

As the line above suggests, the addition of new jobs will be for 2.50 rather than 3.0 and the changes for 3.0 will be adjusting the current jobs to suit 3.0 and addition of couple of jobs like checking the modules distributed under 3.0 etc.

So as proposed (and already implemented) we have try-2.50 (view/flow) similar to our try to handle erp/stable/try-2.50 repo and 2.50 (view/flow) similar to our int to handle erp/stable/2.50.



This section will be filled with the creation/implementation of the repositories, as the changes in jobs is decided on the basis of what check we are going to enable for the Core and Modules in 3.0.

Changes in Mantis

Now as everyone is adjusting to give some place to 3.0, not mantis has also to dot he same. But as 3.0 is practically not only the core but also a bunch of modules with it, so mantis has some special challenges here:

And to counter all these above we created a new field in Openbravo ERP project (Modules). This field has all the modules which are distributed under 3.0. So from now, if someone wants to report bug against these modules he/she has to go to ERP project then file the bug with Modules field set to the right module name. The reporting of bugs for other modules/core will be as usual.

Example Scenarios

Same as earlier(setting version number to 2.50MPX), as new field has default option of Core.
Go to report issue select OpenbravoERP project and report the bug.
Same as earlier (setting version number to 3.0RCX), as new field has default option of Core.
Only difference here is to select the appropriate module in the "Modules" tab and setting version to 3.0RC1 OR above.
Same as we report any issue for any modules till now. Remember you won't find the modules related to 3.0 under Modules project as they have been moved to OepnrbavoERP project.
Go to report issue select Modules project and report the bug.
Update the issue and change the Modules field to the specific module.
For 2.50: Go to view issues page and select "Product Version" and "Apply filter"
For 3.0: Go to view issues page and select "Product Version" and "Apply filter"
For Any specific module in 3.0: Go to view issues page and select "Product Version" as 3.0 and "Modules" field as the Module name.
Bulbgraph.png   Note: Rest all the cases will work as earlier.




Bulbgraph.png   The default value of this new module field is 'Core', which is suitable for any issue reported against ERP version 2.50/3.0.

Retrieved from ""

This page has been accessed 3,255 times. This page was last modified on 30 November 2010, at 14:34. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.