[10.0][MIG] mgmtsystem_nonconformity_project #191
Conversation
|
The current migration strategy was designed to make simple the most common use case: migrating a module from the previous version to the current one, that had no later changes added to it. In this case, you were able to start migrating a 8.0 module just by making it installable and making the needed changes, without any complicated git magic. It's more efficient to have the 9.0 PR finished and merged before making the 10.0 - it will save you from repeating fixes. But nothing prevents you from working on the 10.0 at the same time. |
| If you spotted it first, help us smashing it by providing a detailed and welcomed feedback `here <https://github.com/OCA/ | ||
| Management-system/issues/new?body=module:%20 | ||
| mgmtsystem_nonconformity_project%0Aversion:%20 | ||
| 9.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_. |
There was a problem hiding this comment.
| 9.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_. | |
| 10.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_. |
| { | ||
| "name": "Management System - Project", | ||
| "version": "1.0", | ||
| "version": "10.0.1.0.0", | ||
| "author": "Savoir-faire Linux,Odoo Community Association (OCA)", | ||
| "website": "http://www.savoirfairelinux.com", |
There was a problem hiding this comment.
| "website": "http://www.savoirfairelinux.com", | |
| "website": "https://github.com/OCA/management-system", |
| <field name="model">mgmtsystem.action</field> | ||
| <field name="inherit_id" ref="mgmtsystem_action.view_mgmtsystem_action_tree"/> | ||
| <field name="arch" type="xml"> | ||
|
|
| <field name="action_type"/> | ||
| <field name="complete_name"/> | ||
| </field> | ||
|
|
| <field name="model">mgmtsystem.action</field> | ||
| <field name="inherit_id" ref="mgmtsystem_action.view_mgmtsystem_action_form"/> | ||
| <field name="arch" type="xml"> | ||
|
|
| <field name="name" position="replace"> | ||
| <field name="action_type"/> | ||
| </field> | ||
|
|
| <field name="project_id" colspan="4" | ||
| attrs="{'invisible' : [('action_type', '!=', 'project')]}"/> | ||
| </field> | ||
|
|
#159
This is the real version that I wanted. #190 was just to get moved up to v10. I know you'll complain that this PR wasn't following the technical and I didn't.
But #190 isn't merged. And I tried branching off of my local copy of that branch to create v10, and that pulled in years of commits, like has been the bane of my contributions in project. I tried a modified version of technical:
And that generates no changes. I would very much like to help migrate OCA modules, and I'd like to follow the workflow that the docs require. But I never have been able to create a v10 PR that actually was correct and only included my commits.
This is doubtless my fault, but just as certainly, it's an odd workflow to have 8,9,10 branches, all containing v8 code, and where v10 code is desired, yet v9 must be done first, yet where v9 and v10 have no continuity.
I understand that it makes modules much more discoverable to have all branches include all modules. But it terms of workflow, well, let's say that it's beyond annoying.
I know you can't help everyone..but is there something you can do other than tell me to follow the directions, which I'm already well enough aware of? My email address is in the README.rst; I'd be happy to buy some coffee & donuts to someone who'll get me through this merge mess.