openerp-expert-framework team mailing list archive

[Hiren <hiren@xxxxxxxxxxxx>]

Reply inline.

On Tue, 05 Mar 2013 16:36:39 +0100
Olivier Dony <odo@xxxxxxxxxxx> wrote:

> 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
> 

I had found the script and had a look through it, thanks for the link.

> 
>  >> 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.
> 

Ah thanks! This clears up a lot of upgrade questions for me, appreciate
this info thank you.

> 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
> 

Again, very useful to know thank you, I will keep in mind to only "-u
all" if looking for a specific fix in the menu's etc, we will otherwise
not do this if just an openerp server restart is enough for general
updates to get bug fixes and load new python code.

> 
> > 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.
> 

This makes sense. This is exactly what I'm going to do for production
systems.

> 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.
> 

Interesting, look forward to seeing this in action. Thank you for the
reply and info in this email, clears up a lot of questions around
maintaining a production openerp system, and definitely sheds some
light on the path maintaining a given stable branch with minimal
hassles, yet at the same time, updating enough to keep getting fixes
into ones prod environment.


-- 
Hiren
hiren@xxxxxxxxxxxx