As far as I can understand, we have the same complexity (we have to use git filter) in all solutions if we want to keep the history before and after the creation of the new branch. This complexity can be solved by providing the right steps in the wiki.
Main differences are the side effects:
Option 1 (empty branch)
There is no outdated modules sitting there for 9.0 and later version. Every module you see works on version 9.0. No need to filter. No need to update our scripts and infrastructure. Metafiles can be easily created using the latest template from maintainer-quality-tools.
Option 2 (installable = False)
We have to check the installable flag when pushing to Transifex, when testing on Runbot, when packaging, etc. We basically have to filter everywhere (and maybe in some places where we don't have the control) because we can no longer assume that having a module in the 9.0 branch means it works on version 9.0. For 10.0 branch, we will end up with not-migrated modules from 8.0. Metafiles will need to be migrated manually.
Option 3 (remove modules)
Same as 1) but metafiles will need to be migrated manually.
If I am missing any drawback to option 1, please let me know.
-- ----- Le 31 Aoû 15, à 18:07, Daniel Reis <firstname.lastname@example.org> a écrit :
+1 (514) 276-5468 #126
And another one is that you cannot merge branch 8.0 against 9.0 for unported modules. If we solve the problem with Odoo loading some parts of uninstalled modules, I would prefer option 2 over 3. Option 1 is still my favourite, but has some drawbacks that we have solved also.
You can, using exactly the same method prescribed for option 2.
I tested that, and found a troubling issue affecting coth option 2 and 3:
Using `git checkout 8.0 -- module` command won't bring the change history after 9.0 was created.
Doing so will require some more sophisticated methods.
Some sort of partial rebase.
Probably that sends options 2 and 3 back to the git-filter path too.
Post to: mailto:email@example.com