openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 03/04/2013 01:40 PM, Hiren wrote:
> On Mon, 4 Mar 2013 07:59:32 -0430, Nhomar wrote:
>>
>> Scripts I think are in lp:openerp-tools where there are all thing
>> related to openerp automation things I  openerps servers.
>>
> Thanks will have a look at the openerp-tools repo.

Correct, for example the script that builds the 7.0 nightlies is here:
http://bazaar.launchpad.net/~openerp-dev/openerp-tools/trunk/view/head:/packaging70/package70.py#L272


>> About compatibilty, theorically they are, after any update dont
>> forgat do a -u all -d database as parameters to allow update strings
>> and some things in views.
>
> Why would 7.0 stable branch introduce incompatibilities? It doesn't
> make sense. Most open source projects tag/branch a release and then only
> bug fixes get back ported into that, while features go into trunk, to
> become 7.0.1 a few weeks later, or whatever. Why do openerp do it this
> way?

That's more or less what happens. The stable release policy[1] states that 
there must not be any database schema change on stable series. The team in 
charge of the stable branches keeps all changes as low-risk as possible. As a 
result you should not need to do anything after an update, except restart the 
OpenERP server to reload the Python code.

There may be occasional bugfixes that require changes not only to the business 
logic but also to the data or metadata that is installed in the database by the 
modules (such as menus, views or access rights). In that case an extra update 
step is required if you want to benefit from the fix, and you can normally skip 
it unless you are looking for that fix specifically!
To force a resync of all module data in the database you can start OpenERP once 
with the "-d <DB> -u all" parameters or use the Settings menu in OpenERP to 
force an update of the "base" module.
Forcing such a re-sync may have side-effects if you have modified the original 
module data, so you should not do it unless you really need it for a specific 
bugfix.

[1] http://v6.openerp.com/release-policy


> Debs is what all open source projects use for production (on debian
> and friends), again, why do openerp recommend version control? Debs are
> meant to make sys admin for upgrades etc easier. We're using the debs,
> and they work well, how has bzr saved your life in a way that the
> nightly debs couldn't?

You can perfectly work with debs if you like, just like Windows users can work 
with the all-in-one installer only. Using the version-controlled source is only 
needed when you're in development mode or you technically need fine-grained 
control over individual updates.

By the way for OpenERP 7.0 the built-in update mechanism should be live soon: 
you'll simply have to click on "Update All" in the list of available updates, 
and the system will do everything for you, no need to reinstall an updated package.