Precisamos definir algumas praticas de desenvolvimento na comunidade, a começar pelo fluxo de desenvolvimento e disponibilização de versões.
Atualmente o OpenRedu utiliza o Feature Branch Workflow para receber contribuições no código, que após revisão são integradas ao branch master, tornando-se disponíveis para deploy em produção. Uma abordagem adequada a Rolling Releases.
Considerando o atual contexto da comunidade, acredito que Fixed Releases seja uma abordagem mais adequada por permitir a disponibilização de versões mais estáveis e um planejamento mais adequado do ciclo de desenvolvimento.
Para apoiar essa abordagem, podíamos adotar algumas praticas do Gitflow no modelo de desenvolvimento.
Li os links que você passou e achei muito interessante a estrutura do git-flow. Só conhecia o feature branch workflow mesmo. O git-flow é bem mais robusto que o atual feature branch workflow. Gostei principalmente da noção de tags e releases pois deixa tudo mais organizado e há uma idéia de planejamento para os releases.
Acho importantíssimo adotarmos também o versionamento do Semantic Versioning. Assim poderemos saber qual versão o Openredu está rodando em cada instância, saber quando uma nova versão não for compatível com versões anteriores, e todos outros benefícios que esse método traz.
Concordo com o uso de GitFlow e de Semantic Versioning.
Com a expansão do uso do OpenRedu, precisaremos lidar com diferentes ambientes e necessidades; dependendo do contexto, mudanças constantes de UX ou funcionalidades novas apenas funcionais - mas com baixa qualidade - podem ser prejudiciais a adoção, então o travamento em uma versão estável (branch master do GitFlow) naquele ambiente seria aconselhável.
A adoção dessas duas metodologias tem baixo custo (inclusive ferramentas como Tower e SourceTree suportam nativamente gitflow) e facilitaria o trabalho de integração contínua.
Que tal a versão resultante das contribuições da cadeira de ESE 2015.2 ser definida como 1.0.0 e, a partir dai, as duas práticas seres adotadas (e documentadas na Wiki)?
Concordo em usar o GitFlow, pois organiza muito melhor, para controlar o trabalho da comunidade e também para lançar versões. Acho importante manter um branch de desenvolvimento, que contém todo o trabalho que está feito, mas não necessáriamente está em produção, deixando o branch master com a versão de produção, justamente como o GitFlow sugere. Fica muito mais fácil de corrigir bugs urgentes que devem ser corrigidos a partir da versão de produção, e não necessariamente quando for lançar uma nova versão (quando acontece o merge do branch do desenvolvimento com o master).
Eu já utilizo o Git-Flow em vários projetos, e na minha opnião é a melhor abordagem.
Pessoal, concluímos a elaboração de um Documento(wiki) de boas praticas de desenvolvimento a ser adotado pela comunidade… Tentamos abordar as sugestões aqui propostas, mas fiquem a vontade para sugerir melhorias:
