Regras para Desenvolvimento LBR

This Wiki is read-only for reference purposes to avoid broken links.

Regras para desenvolvimento para a Localização Brasileira. Este documento está sob revisão da Comunidade

Estrutura do Projeto e tomada de decisões

Responsáveis técnicos e funcionais: TBD Antigos: Fernando Cezar Lucktemberg, Ricardo Alexsander Santana

Regras básicas para efetuar commit

• TBD code flow no repositorio...
  • TBD branch / FR / BF -> trunk -> freeze -> tag (release)
• Faça o commit na primeira hora disponível, ou seja, só faça o commit se você tiver disponibilidade para suportá-lo ou revertê-lo em caso de problemas.
• Sempre atualize o seu código antes de efetuar o commit. Alguém pode já ter modificado algo.
• Sempre referencie o BF ou FR no comentário do commit. Inclua a URL do tracker, e um breve comentário sobre o que está sendo enviado.

Trunk

• (TBD já que mudamos para Mercurial) Fazer commit no trunk é um privilégio, não um direito! Para ter autonomia, o desenvolvedor tem de ter responsabilidade. A responsabilidade do desenvolvedor será analisada pelos responsáveis técnicos e desenvolvedores que já possuem direitos de commit.
• Novos desenvolvedores deverão submeter patches para avaliação e posterior aplicação no sistema. Após 10 contribuições, este desenvolvedor poderá pleitear o direito de fazer commit diretamente no trunk.
• Lembre-se, quem faz o commit tem a responsabilidade total sobre suas ações, se o desenvolvedor estragar alguma coisa, este deve fazer o máximo possível para resolver o problema por conta própria, e não desenvolver pela metade para que outros finalizem / corrijam.
• Toda e qualquer modificação deve ser associada a um BF (Bug Fix) ou a uma FR (Feature Request), e quando cabível, aprovada pelos administradores do projeto.

FR's

• Todas as PROPOSTAS de novas funcionalidades devem ser comunicadas para o time de funcionais, que decidirá sobre a aprovação ou não de tal funcionalidade. Após aprovada a nova funcionalidade, o time de técnicos poderá propor formas de resolver o problema para o proponente.
• Para ser integrada no trunk, essa FR deverá estar completa, em pleno funcionamento, de acordo com a especificação. Para não ter problemas com tarefas muito grandes, quebre a especificação em pequenas partes. Não esqueça também de criar dados de exemplo para o uso da FR no GardenWorld

BF's

• Todas as correções que alterem funcionalidade devem primeiro ser comunicadas ao time de funcionais. Se for correção de código falho, a correção pode ser feita diretamente, seguindo o mesmo padrão de mentoria do projeto oficial.

Scripts de SQL

• Todos os scripts de SQL devem conter a versão para os bancos de dados suportados pelo sistema.

Branches

• Caso o desenvolvedor tenha uma proposta que agrade os responsáveis técnicos/funcionais, e estes aprovem, poderá ser criado um branch no SVN.

ID's de sistema

• Todos os desenvolvedores que forem desenvolver uma funcionalidade LBR, deverão usar o gerenciador de ID's.

Formatação de código fonte

• Todo código deve ser formatado com o padrão assumido pelo projeto. Este padrão pode ser encontrado em (endereço para o local aonde encontrar o xml para carregar no eclipse).
• Use nomes de variáveis que façam sentido. Somente no caso de loops, é aceitavel o uso de uma variável que se chame i, j, ou qualquer outra letra.
• Variáveis, métodos, classes e comentários devem ser nomeadas em inglês, salvo casos onde existam documentos oficiais que nomeiem as variáveis, métodos ou afins
• Não duplique código
• Antes de fazer um commit execute o comando de Organizar os Imports no Eclipse (Source > Organize Imports) ou Command + Shift + O (Mac) / CTRL + Shift + O (Linux)
• Tente usar constantes ou crie uma variável na tabela AD_SysConfig, não escreva código hardcoded.
  • No caso do uso de variáveis na tabela AD_SysConfig, parâmetros técnicos devem ser criados aqui, no caso de coisas que o usuário tem poder de decisão, criar uma janela (a não ser em casos específicos).

(concluir padrão para comentários do código).

Mudanças em Views

As views que forem modificadas devem ser criadas da seguinte forma: Um script contendo a view modificada Outro script contendo as colunas criadas na view

Notas importantes

• Antes de modificar qualquer código, o desenvolvedor deve entrar em contato com quem desenvolveu inicialmente, relatando o motivo da modificação e o BF gerado no projeto.
• Caso o desenvolvedor discorde, o time técnico deverá ser acionado para dirimir a questão. Caso o desenvolvedor original não responda à requisição em 2 dias úteis, a modificação poderá ser feita sem o consentimento do mesmo.
• Este documento é baseado nas regras do projeto Adempiere (Oficial).

Manuais

• Toda nova funcionalidade deve ser devidamente documentada antes de ser colocada no trunk ou em produção.
• Força tarefa para documentar o que já temos pronto hoje, explicativo para que usuários novos possam implantar o sistema.

Release de novas versões

• Releases oficiais sempre devem ser provenientes do Trunk
• Releases oficiais devem ter o tag de alpha, beta, release candidate ou stable
• Releases não oficiais devem ser provenientes de branches
• Neste caso a release deve ser nomeada obrigatoriamente com o nome do branch
• Neste caso não se usa o tag alpha, beta, rc ou stable, somente o nome do branch e data.
• Releases seguirão o plano de desenvolvimento contido no site oficial do projeto, um mês antes de cada release o trunk sofrerá um congelamento.

Ficam abertas as seguintes necessidades

• Documento de especificação? Modelos?
• Documento com as regras a serem seguidas no desenvolvimento.