PORQUE MUDAR PRO XSDATA

xsdata é uma lib absurda! apareceu do nada em 2020 e muita gente ja considera a melhor lib para lidar com xsd independente de qualquer linguagem, o que não é pouca coisa considerando os investimentos que tiveram nos projetos concorrentes por 2 decadas, Java ou .Net em especial.
o xsdata tem uma suite de tests super completa, é testada com os xsds mais exigentes que existem (tests do W3C, UBL...)
o codigo do xsdata é examplar, muito bem testado
o desenvolvedor do xsdata é super reativo
xsdata deu conta de todos documentos fiscais do Brasil com 10x menos trabalho do que o generateDS (eu tinha feito uns 6 patches no generateDS para suportar a nfelib 1.x).
xsdata foi pensado para lidar com pacotes de varios xsd e includes de arquivos, o que é exactamente o que temos no Brasil. Com o generateDS a gente tinha que fazer varias gambiarras para suportar isso, como conservar apenas alguns arquivos geridos para não duplicar muito codigo.
os bindings xsdata são dataclass Python padrão. Nisso é um codigo 5x mais compacto do que os bindings geridos pelo generateDS. Isso nos permitiu de trabalhar tudo na mesma branch com os schemas e o codigo gerido. Enquanto na versão 1.x a gente tinha os schemas na branch master e a gente gerava os bindings numa outra branch com muito codigo, como se fosse um pouco um codigo compilado onde seria muito mais dificil acompanhar mudanças (atualizar o generateDS mudava bastante o codigo gerido por examplo). Com xsdata, apenas evoluçoes dos esquemas mudam o codigo dos bindings e fica super facil acompanhar.
assim como o generateDS, o xsdata foi pensado para ser extendido e gerar outros modelos. Foi o que eu fiz pro Odoo no https://github.com/akretion/xsdata-odoo para gerar os mixins abstratos dos modelos de dados fiscais no Odoo, nosso foco principal na Akretion.
enquanto isso, o generateDS serveu, mas hoje esta no caminho de ser abandonado pro xsdata. O codigo do generateDS não é muito moderno, da até um pouco de medo e esta hospedado no mercurial no Sourceforge hoje, algo que ninguem mais usa...

para maiores informações: https://www.youtube.com/watch?v=6gFOe7Wh8uA

COMO MIGRAR

O caminho onde estão os bindings mudou. Pois com a experiença da nfelib 1.x, refinamos para suportar mais facilemente varios documentos fiscais e varias versões. Em especial, agora apenas 2 digitos caracterizam a versão nas pastas: assumimos que se menos de 2 digitos mudam se trata de uma mudança menor que iria apenas atualizar os schemas existentes enquanto se tiver uma mudança no primeiro ou segundo digito (por examplo NFe 4.0.x para NFe 4.1.x) ai poderiamos ter varias pastas para suportar varias versões ao mesmo tempo.
O nome das classes dos bindings mudou. O xsdata deixou tudo mais "pythonico", os nomes ficaram parecidos. Basta buscar pelo nome da tag original nos arquivos de bindings para ver como ficou o nome com xsdata.
Salve algumas exceções que vc pode encontrar la lista de substituçoẽs https://github.com/akretion/nfelib/blob/master-xsdata/.xsdata.xml#L20 o nome dos campos não mudou e ficam igual dos elementos dos xsd.