Release Management/Mantis and CI structure with 3.0
Contents |
Mantis and CI welcomes 3.0
Introduction
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.
- Her is the overview of the jobs introduced for 2.50:
- Changes for 3.0
- Changes in current jobs & addition of new jobs.
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:
- The user should be able to report a bug against the module (if he know the relation of the bug with the module).
- Developer should be able to reassign the bug to any specific module.
- For reporting it should be easy to check the bugs reported for any module under 3.0.
- etc. etc.
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
- Reporting a bug for 2.50.
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.
- Reporting a bug for 3.0 (and don't know the module name).
Same as earlier (setting version number to 3.0RCX), as new field has default option of Core.
- Reporting a bug for 3.0 (and I know the module name).
Only difference here is to select the appropriate module in the "Modules" tab and setting version to 3.0RC1 OR above.
- Reporting a bug for module not included in 3.0 distribution.
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.
- Re-assigning a bug to some specific module.
Update the issue and change the Modules field to the specific module.
- Searching modules related to 2.50/3.0 OR for any particular module in 3.0.
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.
- Modules Field on "Report Issues Page".
- Modules Field on "Search Issues Page".
- Modules Field on "View Issues Page".
![]() | The default value of this new module field is 'Core', which is suitable for any issue reported against ERP version 2.50/3.0. |