Adoção do Versionamento Semântico 2.0.0

[williamespindola]

No wiki onde fala sobre o versionamento temos uma simples exemplo "x.y.z" não somente a exemplificação mas também a adoção do Versionamento Semântico 2.0.0 seria importante. Onde:

Dado um número de versão MAJOR.MINOR.PATCH, incremente a:

versão Maior(MAJOR): quando fizer mudanças incompatíveis na API, versão Menor(MINOR): quando adicionar funcionalidades mantendo compatibilidade, e versão de Correção(PATCH): quando corrigir falhas mantendo compatibilidade. Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato MAJOR.MINOR.PATCH.

Mais informações no link acima.

[robmachado]

SIM e .....

[robmachado]

Vamos estudar um pouco esse assunto ...

Todo meu trabalho hoje esta focado na versão que está em develop. Com o NFe já refatorado e bastante melhorado. Porém faltam:

• testes (phpunit)
• refatorar CTe, e MDFe

Com isso passo a versão develop (4.0.dev) para master (stable 4.0.0) ... ai surgem algumas questões sobre o versionamento tão detalhado. Qual seria a finalidade de manter tags com as correções de BUGS.. nenhuma

Qual seria a necessidade de manter verões muito ultrapassadas tendo em vista que grande parte das alterações são causadas por mudanças que a própria SEFAZ impõe.

Apenas quando existe uma refatoração grande como foi o caso de develop acho importante guardar a versão antiga. Veja que essa API é profundamente dependente das alterações da SEFAZ e em principio serão introduzidas apenas ajustes as mudanças da SEFAZ.

Pelo menos até que outra REFATORAÇÃO seja feita ai teremos novamente a mudança do numero MAJOR.

Outra coisá normalmente é IMPOSSÍVEL usar uma versão desatualizada, ou seja é uma coisa diferente do que um "PHPUNIT", "TCPDF", "MPDF", "ZEND" ... por exemplo onde temos várias versões a TODAS funcionam. com mais ou menos recursos mas funcionam.

No nosso caso versões antigas NÃO FUNCIONAM mais, pois o que mudou normalmente foi a SEFAZ.

[williamespindola]

Vejo os seguintes quadros:

Estado	Versão
Última versão estável	3.0.0
Ouve alguma alteração SEFAZ	3.0.1
Ouve uma correção de bug no código que não funcionava no computador do zé	3.0.2
Houve uma melhoria no código, mas permanece a mesma api	3.1.0
Ouve alguma alteração SEFAZ	3.1.1
Ouve uma alteração no código que alterou a interface da api	4.0.0
Ouve alguma alteração SEFAZ	4.0.1

Quando instalamos um sistema via composer o correto é usar apenas MAJOR.MINOR.x, pois desta forma sempre pegamos o PATCH mais atual. Assim instalando a versão 3.1.x estamos pegando a 3.0.2.

Mas um dos principais problemas para tratar nesta arquitetura são as regras da SEFAZ, elas não estão totalmente encapsuladas então sempre teremos este problema de uma minima alteração feita que invalida a versão anterior totalmente.

Me diga, em geral como são tratadas as regras da SEFAZ? São sempre cálculos ou processos mais complexos? Me de um exemplo, por favor.

Acho que se conseguirmos trabalhar com algum tipo de dependência e manter as regras fora do parser, em um módulo apenas para estas regras, pode facilitar a manutenção.

[robmachado]

Negativo;

Mudam estruturas de documentos, regras de acesso, urls de acesso, conteúdos, métodos, requisitos, ...

Por exemplo a SEFAZ de GO está exigindo que o certificado contenha toda cadeia de certificados, outra SEFAZ exige uso de TLS ao invés de SSL, uma SEFAZ mudou o numero de versão de um webservice, outra mudou o URL e o nome do método, a receita desabilitou a forma de buscar as notas destinadas (mudou o método e todas as estruturas), e o por ai vai ,,,, muitas alterações tem várias outras implicações em outras estruturas.

O que eu consegui refatorar foi retirar as classes centrais uma série de estruturas e coloca-las em uma subpasta Common e essas classes devem mudar menos que outras.

Roberto

[robmachado]

A ideia é fazer isso mas apenas quando a BRANCH DEVELOP estiver totalmente refatorada, nesse ponto será enviada para MASTER e será criada a TAG v4.0.0 (stable).

A partir desse ponto as correções passarão a ser feitas em MASTER e a cada alteração significativa (entenda-se, correção de BUG, mudanças de estrutura, etc.) uma nova TAG será criada. As correções de BUGS afetarão apenas o "MINOR" ou seja o último digito e as correções de estrutura alteração do numero intermediário de versão ... o numero "MAJOR" somente será alterado caso haja uma refatoração da API ou de parte significante da mesma.

A BRANCH DEVELOP deverá ser usada apenas durante e quando houver uma REFATORAÇÃO, onde muitas estruturas e códigos são modificados e muitos teste e checagens são necessárias e existem mudanças intensas no código. Por exemplo se eu estivesse controlando as mudanças com TAGS hoje teríamos a versão 4.0.675 ou algo que o valha.

Eu mesmo uso esses recursos do GIT a pouco tempo (menos de 4 anos) e ainda estou aprendendo.

Portanto qualquer ajuda será sempre bem vinda !!

[walkeralencar]

Roberto, Essa abordagem é espetacular, é possível organizar as milestones, focar as issues para sanar problemas realmente relevantes, e facilitar a colaboração no projeto.

Engraçado, que estamos nos direcionando para algo similar ao que havíamos proposto em 2009.

Tenho uma demanda para o projeto em breve, o que me permitirá algumas contribuições novamente. ;)

[robmachado]

Walker;

Tudo bem ?? Que bom falar contigo.

Sim essa ideia é ótima mas vamos aplica-la a partir das classes refatoradas versão 4.0 em diante. Ainda falta refatorar CTe e terminar MDFe para mover a branch DEVELOP para MASTER. A partir desse momento sim podemos manter versões semanticas usando TAGs .

Mas ainda temos serviços a fazer e coisas a discutir sobre esse assunto. Muitos usuários estão vivendo no passado e tem enormes dificuldades com namespaces, composer e PSR-4 que são padrões que estou adotando e usando em meus projetos. E o nível de contribuições reais (código) para a API é muito baixo.

Uma coisa muito importante é refazer os MILESTONES e ISSUES para isso porém eu não uso CTe nem MDFe então meu tempo dedicado a isso tem sido muito pequeno. A parte de NFe já está bem adiantado.

Acredito que com essa refatoração (já feita) irá propiciar mais estabilidade ao código mesmo para futuras refatorações e mudanças na SEFAZ, garantindo que as classes e métodos permaneçam mais estáveis e usáveis por um longo período de tempo.

Estou no aguardo de sua ajuda !

Roberto