openerp-community team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 04/08/2013 05:09 PM, Alexandre Fayolle wrote:
> If we are to accept changes which affect db layout, we need a clear
> policy about what changes are acceptable, and how to label them. At the
> very least, updating the version number of the addon should be
> required, a tag in the commit message and a migration script (if
> required) should be part of the MP.

Hi Alexandre,

As there seems to be a majority for a single branch, this seems to be 
the approach to take.

However, we could get in trouble by incrementing the module version 
number. Although these version numbers are willfully ignored by OpenERP 
SA themselves even between major releases, if for instance the eventual 
solution to the current datamodel debate regarding partners and contacts 
would require a migration, a version number increase of the affected 
modules in upstream would be unavoidable. Should the version number in 
the backports branch happen to be incremented already to the same 
version, no conflicts would occur in the replay process and the 
migration would not take place at the time of the database upgrade.

The exception would be if a migration script was necessary for a 
backport specific change (again, to trigger these scripts to run) but I 
think that should not be the case.

But a tag to filter by would be very useful. Preferably this should be 
placed on the first line of the commit message so that simple grep on 
the bzr log reveals the revisions which require a database upgrade. Can 
we agree on adding a second commit tag "[UPG]"? A sample commit message 
would then look like

  [FIX] [UPG] lp:707923, account: Effective vertical tax rounding by 
increasing precision

Cheers,
Stefan.