Release Management/Mantis & CI structure with 3.0

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 accomodate 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 will the jobs in the hudson, i mean 3.0 will use the existing jobs/views (try, int etc) and 2.50 will have its own new jobs and views.

As this upper line 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:
  • stable/2.50

• • stable/try-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 chalanges here:

- The user should be able to report a bug againt 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 Openrbavo ERP project (Modules). This field has all the modules which are distribited 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.

NOTE: The default value of this new field is Core, which will is suitable for any issue reported again 2.50/3.0.