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.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
