openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On Tue, Oct 29, 2013 at 12:32 AM, Stefan Rijnhart <stefan@xxxxxxxx> wrote:

>  On 10/28/2013 11:07 PM, Fabien Pinckaers wrote:
>
> - one can not use it in production since you can not easily do "bzr pull"
> to apply latest bugfixes
>
> I don't even know what you mean by this. I pull OCB-branches on a daily
> basis. Because of the nightly replay process, they are never more than a
> day behind the official ones.
>

I think Fabien meant that a non-technical user can't just do a bzr pull of
the branches and restart their servers, they would have to know how to read
the commits, what to update, etc. (see below)


I understand that the bug fixing policy is due to the out-of-the-box
> implementation strategy, where the consultant makes a lot of changes in the
> interface that would not survive a module upgrade.
>

Wait a minute, that's not correct! I remember explaining it at the
community days discussion, and even seem to recall that Alexandre was
surprised to learn about it (due to his more recent arrival in the
community).

The stable policy is *not* designed to preserve changes that do not survive
module updates[1]. It represents the very minimal set of things that we
know must not change to guarantee the product stability to the customers.
There are many many customers who will never perform any -u at all and will
simply reinstall the newest all-in-one on top of their install, or pull the
latest source and restart.
And actually, it must be as simple as that! It's pretty obvious if you
think about it.
OpenERP has an API and there is no good reason to change it in the middle
of a stable series. Just like you would not expect the Python stdlib to
break compatibility with existing programs at every patch release, or the
linux kernel API to change in the middle of a stable branch or to suddenly
require a manual task to keep programs running. Those kind of policies do
not bear "exceptions" easily.
Yes, OpenERP is certainly not as stable as those examples, but that will
not get better unless we to start acting like we mean it.

So the stable policy is here to make sure we never break userland:
- Yes, stored columns (and their constraints) are part of the API. If you
change them, not only could it break systems of users who simply reinstall
the latest code over their existing installation, but it can also trigger
more subtle problems due to inheritance peculiarities. And it also means
you cannot safely pull in a directory where load-balanced workers are
running, for example.
- Yes, changing workflows can be dangerous if the existing records risk
ending up in inconsistent states. That really depends on the change.
- Yes, changing public method signatures is a sure way of breaking random
community/custom modules.
- Yes, making inter-dependent patches in two different projects at the same
time is a sure way to trigger errors for many users
- and so on...[2]

I'm not sure why everyone here seems to think the stable policy is an
optional joke. Most frameworks have a stable policy, based on their own
definition of "stability", and the contributors learn them and understand
them.

And if allow me to repeat once more: there is almost no chance you'll
encounter a bug that cannot be fixed decently without breaking the policy.
It just takes a bit more thinking, and that's always good anyway. I haven't
checked but I'm sure it's true for your PO bug too.
Why not take the policy for granted instead of seeing it as an optional or
useless constraint?

And what is *so* incompatible with the OCB goals here anyway? ;-)



[1] We get companies started on OpenERP Online every day with
customizations that perfectly survive monthly migrations from one SaaS
branch to the next.
[2] See draft policy: http://pad.openerp.com/stable-policy