Forward-port / Back-port TODO

[rvalyi]

Forward port from 12.0 to 13.0/14.0

• [14.0][FORWARD PORT] ref group tax #1624
• [13.0][10n_br_base][FORWARD PORT] port PRs 1641 and 1651 #1659
• [12.0] fix erro causado pelo fiscal dummy  #1690 no modulo l10n_br_nfe [14.0][l10n_br_nfe] mig l10n_br_nfe #1674
• [14.0][l10n_br_fiscal][FORWARD PORT] port pr 1652 #1759
• [FIX] typo in NFe Document Related #1780 no modulo l10n_br_nfe [14.0][l10n_br_nfe] mig l10n_br_nfe #1674
• [12.0][FIX] Confirmação do documento quando o emitente é o parceiro #1814
• [12.0] Alterações relacionadas ao campo ind_final #1809
• [12.0] Definida as opções no_create e no_create_edit em alguns campos nas visões #1823
• [12.0] Adicionado índices em alguns campos chaves #1764
• [12.0][l10n_br_fiscal] fiscal usability #1610
• [12.0][FIX] Cada empresa deve ter o seu próprio fiscal dummy #1804 no modulo l10n_br_fiscal
• [12.0][FIX] Cada empresa deve ter o seu próprio fiscal dummy #1804 no modulo l10n_br_account [14.0][MIG][l10n_br_account] mig l10n br account #1688
• [12.0][IMP] Validação do XML na NF-e #1815 no modulo l10n_br_fiscal
• [12.0][IMP] Validação do XML na NF-e #1815 no modulo l10n_br_nfe
• [12.0][REF] Movido o método de Criação dos Comentários do modulo l10n_br_account para o l10n_br_fiscal #1849 no modulo l10n_br_fiscal
• [12.0][REF] Movido o método de Criação dos Comentários do modulo l10n_br_account para o l10n_br_fiscal #1849 no modulo l10n_br_account
• [12.0][ADD] Module l10n_br_account_nfe, inclusão das Tags Fat, Dup e Pag #1853 no modulo l10n_br_fiscal
• [12.0][ADD] Module l10n_br_account_nfe, inclusão das Tags Fat, Dup e Pag #1853 no modulo l10n_br_nfe
• [12.0] Criar campos relacionais para faturas de retenções de impostos #1996
• [12.0][FIX] invoice_line_tax_ids field view widget #1997
• [12.0] l10n_br_account: Considera ind_final no calculo dos impostos do account.invoice #2017
• [12.0][FIX] Correções para o Boleto Santander. #2012 [14.0][FORWARD-PORT][l10n_br_account_payment_brcobranca] - Santander CNAB 400 #2848

Backport port from 14.0 to 12.0

• [12.0][BACKPORT][l10n_br_coa] manifest #1595
• [12.0][BACKPORT][l10n_br_coa_simple] maintainers + dev status + desc #1597
• [12.0][BACKPORT][l10n_br_fiscal] clean related fields.Selection #1668
• [12.0][BACKPORT][l10n_br_fiscal] fiscal backport #1680
• [12.0][l10n_br_account][FIX] fix typo: stored=True -> store=True #1700
• [12.0][l10n_br_nfe][BACKPORT] l10n br nfe backport #1702
• [12.0][l10n_br_fiscal][BACKPORT] backport pr 1759 #1760
• backport ? [14.0][IMP] l10n_br_fiscal l10n_br_sale: Movido parâmetro de "Custos de Entrega" para o modulo l10n_br_fiscal #2136

[rvalyi]

The idea behind this issue is to update it the same way as we do with Shopinvader shopinvader/odoo-shopinvader#416 or how Acsone does it internally for mis-builder https://github.com/OCA/mis-builder/pulls?q=is%3Apr+is%3Aclosed+PORT .

Rationale: basically at Akretion we participate to the maintainance of around ~70% of the OCA/l10-brazil and some of our customers will still be on v12 in 2022. Yup. We won't take any v13 project, but we will soon focus on v14. Some core modules are easier to migrate with a v13 step than straight to v14, but as for us we will provide v13 PRs only for the very core modules (like l10n_br_account and l10n_br_nfe) and we won't maintain v13 actively. But of courset if others want to do it that's fine and they will easily be able to backport modules from v14 (rather than front-port from v12). As for ourselves, we think we will phase out 12.0 evolution at the same pace we will adopt v15 eventually (not before early 2022 at least).

It means we need a strict way to port the project PRs back and forth to ensure last features and bugfix are available accross versions and also ensure a smooth migration when upgrading instead of the module being totally different and possibly broken in version N+1. This is also why we should keep modules as simple as possible and prefer breaking things down in several small modules where people are then hold responsible for shit not to happen with the modules they maintain before anything else.

Also this is made possible because we ate the bullet on v12 by converting almost the whole codebase to the OCA pre-commit standards #1445. An ingrate work from the previous months but that is now paying when porting modules much more easily with relitively small diffs.

cc @marcelsavegnago @renatonlima @mbcosta @britoederr @netosjb @felipemotter @rpsjr @bmessiaz @luismalta @gabrielcardoso21 @ygcarvalh @marcos-mendez

What do you guys think? I just wanted the main ideas were clear in plain English but answering in Portuguese is fine.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

[marcos-mendez]

Pois é. Eu ainda to usando algumas coisas da 12 para a 14 então imagina pra 16. Continuo concordando como em 2021