openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Pedro,

about the minor version changes. I think it's too much hassle to maintain.
Imagine all the incremental changes you do when you propose a MP...
Or may be we can decide we maintain it only for a set of very central
critical modules.
But I would rather have this done automatically.
I think for now we could cope with minor numbers not being maintained.

In the future, I think we should follow the idea of Vo Minh Thu
http://assertive.io/ that is an automatic conversion of __openerp__.py to a
Python setup.py, using revision numbers to create the minor version.

BUT, I would suggest, that we change the assertive process a bit: I would
suggest, that modules are split in individual branches (exposed or not)
before having their setup.py generated. That would enable that modules get
their minor version incremented ONLY if they actually received a change
(and we could even say that a translation change doesn't change the minor
number, it would be just about doing it in the .gitignore). That is
important to avoid re-downloading the world when you would do some daily
delta update on some instance.

I would suggest doing that with git because git subtree works and is
extremely fast, unlike bzr alternative for this.
I think a module extraction should look like this:
https://github.com/akretion/oe-addons-subtree-purchase_requisition/tree/trunk-wms
or this
https://github.com/akretion/oe-addons-subtree-account_analytic_analysis
which are modules extracted from OpenERP SA branches after they are
mirrored to Github in first place (automatically).


So to summarize:
1) I think we should keep it simple for now and don't bother with minor
version changes that don't affect the database
2) I think we should work in the long run in idea of Assertive, but
integrating an intermediary branch split before the module conversion so
that we have that minor module version automatically
3) I can help OCA with mirroring OCA branches to Github and and creating
the module extraction scripts.
4) In the eventual case OCA get open to the idea of having *some*
experimental projects moving to Github as their primary forge (and get
mirrored to LP second), with exactly the same review rules, I can help with
enriching the OCA "nag" tools to report properly about the pending merges
on Github along with the work on LP.

There is a problem though in that idea: how developers using the LP
branches would know about minor version number if they only come a the end
of the process when the setup.py is generated. Does it matter?

Of course this is only my opinion and I accept OCA decides otherwise if
many disagree with me on this.

Regards

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com





On Tue, Jan 7, 2014 at 8:50 AM, Pedro Manuel Baeza Romero <
pedro.baeza@xxxxxxxxx> wrote:

> Hi, community,
>
> When we agreed community conventions, we talked about changing version
> numbering in two ways:
>
>    - Change minor version number when *any* fix/improvement/etc that
>    doesn't change DB layout.
>    - Change major version number for big refactorizations or changes that
>    affects DB layout, and create migration scripts if needed.
>
> But I see that pretty no one (including me) has followed this convention
> in the contributions, so I ask for a more strict control of this question
> on the reviewing process or a change in the convention. I think that we
> shouldn't relax this convention, because it's very useful to see a
> different version number when any change is made (and can also benefit the
> update system used by OpenERP S. A.).
>
> Another question is: this must be applied also to OCB branch?
>
> Regards.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>