On Tue, Oct 29, 2013 at 12:32 AM, Stefan Rijnhart <ste...@therp.nl> 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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp