I have merged the first part of modularity project into trunk. This does no add any new functionality, it just contains the new database infrastructure to manage modules which includes a table (AD_Module) to maintain the installed modules in the instance and a reference to this table in many application dictionary tables (you can see the complete list of the affected tables here).
The purpose of this early merge is to try to affect other projects for r2.50 as llittle as possible but, in any case, it would be advisable to synchronize these projects with trunk as soon as possible in order to minimize the risk of conflicts.
A few days ago, we have completed a very significant new project, UUID, which dramatically simplifies the development and portability of new developments in Openbravo as well as streamlines the contribution process. This project has now been merged into the development trunk and all the developers who follow our progress checking out our developer’s edition from subversion can benefit from it.
The purpose of the UUID project is to identify Openbravo ERP database records in a unique way to make possible to multiple developers to create new records in database tables without having to concern about possible ID collisions with other developer’s records.
In release 2.40 and before, this uniqueness was guaranteed assigning to each developer a different range which was called development environment ID, so for features that are developed from the trunk (and that therefore will be delivered with release 2.50), from this moment on, this ID is no longer required, so it is not needed to request for it to be able to develop and contribute it.
Since ID conflicts are no longer an issue, it is now much easier to move custom code and extensions from one instance to the next. This change is the first step in the implementation of the modularity infrastructure which is intended to be completed by 2.50.
One of the consequences of this change is that custom code that was developed for 2.40 is no longer compatible with the trunk and needs some modifications. This is generally not a lot of work but it is something necessary before your code can run with 2.50. You can find detailed instructions on how make this changes here.
Another consequence is that from now on Openbravo ERP requires PostgreSQL 8.3 or higher and the postgresql-contrib-8.3 package.