Publicar os releases em http://boletophp.com.br/#download

[drupalista-br]

@israelst

Tem como você taguiar os releases das versões 1.x e 2.x? Exemplo: https://github.com/drupalista-br/Boleto/tags

Uma vez feito o taguiamento, poderia em seguinda mudar o link de download localizado em http://boletophp.com.br/#download para https://github.com/BielSystems/boletophp/tags?

Assim as pessoas terão uma lista com todos os releases para fazer o download.

Ainda na página http://boletophp.com.br/#download coloque um link para as páginas de instruções da versão 2.x https://github.com/BielSystems/boletophp/blob/2.x-dev/README.txt

Instruções de como taguiar podem ser encontradas em http://learn.github.com/p/tagging.html . Caso tenha alguma dúvida por favor deixe um comentário.

Grato,

[maurogeorge]

Na minha opinião estes releases deveriam ser feitos apenas quando tivermos algo funcional.

Hoje o que temos é a versão procedural funcionando. Esta seria a 1.0.0, depois que mergear a do branch do @israelst nela teremos 1.1.0 se o israel não quebrar nada na api, se não será 2.0.0, acredito que será mais refactories então será 1.1.0. e por ultimo quando tivermos uma versão orientada a objetos, devidamente testada, mergeamos ela e aí sim taguearemos como 2.0.0 pois esta vai quebrar tudo, pois saira do procedural para orientado a objeto.

Lembrando que a ideia do projeto não é manter N versões, apenas taguearemos estas procedurais para projetos legados, e o cara poderia atualizar para o 1.1.0 para ter o código refatorado, mais a ideia é estas versões morrerem.

Outro motivo para não nos preocuparmos com isto agora, é que podemos taguear tudo depois. E como só temos uma versão até o momento, recomendo deixar ela como está.

Abraço

[drupalista-br]

@maurogeorge Esse raciocínio faz sentido para um produto comercial, mas a ideia aqui é atrair colaboradores, não entregar um produto pronto.

O site boletophp.com.br é bem conhecido mas muita gente não colabora porque não sabe como. Então porque não deixar claro no boletophp.com.br o que temos e o que precisamos e como as pessoas podem contribuir.

Além disso, eu não entendo o que você quer dizer com "tivermos algo funcional". Os códigos em ambas as versões são funcionais, não são perfeitos, mas são funcionais.

@israelst eu insisto, coloque mais informações no boletophp.com.br. Se não quiser taguear, que pelo menos coloque os links para ambos os repositórios ( 1.x e 2.x ) bem como o link para readme.txt do 2.x.

Se puder coloque também que precisamos de colaboradores para desenvolver mais plugins de carteiras para o 2.x.

Insisto, precisamos atrair as pessoas, não esconder o trabalho porque achamos que não tá bom, para que o projeto possa crescer.

Basicamente a tática do @maurogeorge é esconder o projeto para que "nós" possamos trabalher nele e mostra-lo somente quando ele estiver "perfeitinho", simplesmente não faz sentido quando trata-se de open source. Mostre o que temos e com certeza receberemos mais feedbacks e possivelmente mais código.

[brunosinister]

Galera não tenho contribuido com códigos por falta de tempo, mas deixarei minha singela opinião.
Bem acho que dividir o projetos em release pode sim ser uma boa e descrever a natureza do proejto open source na página boleto PHP também.
Obviamente que essas tags tem que ser descritivas, no site do boleto php eu faria algo como: baixe aqui versão 1.1.0 stable e 2.0 dev. Para ficar claro que a versão 2.0 está em desenvolvimento porém se o cara quiser baixar testar e reportar melhorias e contribuir ele tem como.
Essa é a forma que grande parte dos projetos open-source trabalha em tem demostrado resultado positivo.

Fica ai minha opinião.

[pedrorocha-net]

Pego o que o Bruno disse, que resume muito do que penso:
"Essa é a forma que grande parte dos projetos open-source trabalha e tem demostrado resultado positivo."

Se queremos que o projeto ande e receba cada vez mais colaboração, o processo deve ser o mais aberto possível à colaboração. Sempre lembrando que aberto não significa bagunça.

[maurogeorge]

Um pequeno disclaimer, apenas para saber se estamos todos alinhados com o projeto. Num futuro proximo, esperamos, não ter versão procedural e orientada a objetos, afinal o PHP rodará ambas, não vai ter ngm querendo fazer download de versão procedural. O @israelst me falou isto e concordo com ele. Ou seja assim que finalizar os refactories do 1.0.0 ele será mergeado no master e lançado como 1.1.0 talvez e aí sim poderemos ter uma versão orientada a objetos, lembrando que esta pode ter seu desenvolvimento em paralelo em feature branchs.

@drupalista-br concordo com a ideia de atrair colaboradores, acho que estamos aqui para isto, se não cada um tinha seu projeto privado e não aberto no github.

Concordo que temos que deixar claro no boletophp.com.br como contribuir.

Quanto ao "tivermos algo funcional", quero dizer que o código para mim confiavel é o https://github.com/BielSystems/boletophp no branch master, que é a versão antiga do projeto, em que os boletos foram impressos e testados.
O https://github.com/BielSystems/boletophp/tree/1.x-dev praticamente o mesmo código, é confiavel pois o que pessoal ta fazendo é testar o código já existente e refatorar.
Quanto ao branch https://github.com/BielSystems/boletophp/tree/2.x-dev é um código totalmente novo orientado a objetos e sem testes, neste eu não consigo confiar, pois provavelmente foi criado a partir do outro procedural, com copy e paste, sem problemas aqui, com tanto que tivesse testes. Apenas olhar o output e assumir que está certo é complicado, além de dificultar refactories e contribuição.
Digo isto pois o que eu estou fazendo em https://github.com/maurogeorge/boletophp/tree/refactory-oop possui muito copy e paste, no entanto nos meus testes eu passo exatamente os parametros que tem no procedural e como resultado do teste tem que ser a saida do procedural. Ou seja to fazendo orientado a objeto e minha asserção é o procedural, to garantindo que neste copy e paste não me passou nada dispercebido.

Ou seja o problema que vejo nisso é o pessoal, começar a contribuir em um projeto sem testes e assim ele ficar. O que não faria sentido pois um procedural sem testes e o orientado a objetos sem testes para o usuário final daria no mesmo só mudaria a interface. E pelo o que disse no paragrafo anterior não tem que ter download disso, branch 2.0 para uso final, não pelo menos agora, deixa a galera baixar o procedural mais que funciona.

Sendo assim volta a reiterar aqui, em uma outra thread o @israelst falou que não deveria/queria, não lembro bem, aceitar código sem testes, eu concordo 100% com isso, de só ter código testado.

Desculpe-me se fiz entender errado, mais esconder não é minha ideia se fosse isso eu tinha um repositório privado e não publico.

No mais keep Hacking pessoal, o importante é aprender e ser divertido.

[maurogeorge]

Fala @brunosinister e @pedrorocha-net,

concordo com ambos de colocar o projeto 2.0 em dev no site para o contribuir, o problema que vejo é o que comentei no comentário anterior, a falta de testes. Se tivesse testado, seria lindo era o cara contribuir e mandar pull request.

E com o que o @pedrorocha-net "Sempre lembrando que aberto não significa bagunça." acho que este é o meu medo, de já começar com o pé errado de tá sem testes e incentivar isto.

Abraço

[drupalista-br]

@maurogeorge

Pelo visto independente do que a maioria quer você e o @israelst vão fazer do jeito que vocês querem. Boa sorte, eu estou fora.

Quanto ao branch https://github.com/BielSystems/boletophp/tree/2.x-dev é um código totalmente novo orientado a objetos e sem testes, neste eu não consigo confiar, pois provavelmente foi criado a partir do outro procedural, com copy e paste

Copy e paste!? Você está muitíssimo desenformado. Eu desenvolvi linha por linha deste código.

[israelst]

Vamos com calma. Primeiras coisas primeiro.

@drupalista-br, sim o site precisa ser alterado para refletir nossos esforços aqui no github com os devidos links, independente de serem versões perfeitas. Criemos issues para isso. O site tem muuuuito a melhorar. Se já tiver alguma coisa em mãos, me manda que eu publico.

Sobre o que o @maurogeorge disse, não pretendemos mergear código sem testes mesmo, por mais que o código tenha sido totalmente reescrito. Aliás, ainda mais quando o código for totalmente reescrito.

E @drupalista-br, pessoalmente, não gostaria que você saísse, por mais que haja pontos de discordância, você é um dos que mais contribui com o projeto (e o que mais commita) e está óbvio que todas as suas iniciativas são intencionando o crescimento dele e cobertas de pensamentos alinhados com a filosofia opensource. Com o perdão do abuso, mas queria pedir que você tenha mais paciência conosco e com as nossas opiniões. Sinta-se livre para tocar seu repositório do jeito que quiser e continuar nos ajudando.

Além disso, tenho me envolvido em muito mais tarefas não ligadas a código do que eu gostaria, acho que isso pode frustrar vocês um pouco pela minha demora em atender às coisas que aparecem. Mais uma vez, peço desculpas pela minha demora.

Algum de vcs estará no FISL na próxima semana? Será uma ótima oportunidade de alinharmos as coisas e resolvermos esses problemas.

[drupalista-br]

@israelst vou ser sincero, a conversa do @maurogeorge afeta os meus nervos. Ele parece um disco arranhado, "não vamos publicar sem testar" (fazer voz engraçada).

Meu, fala sério, tenho certeza que o @maurogeorge é um bom profissional e não é minha intensão ofende-lo ou fazer pouco caso dele, acho super importante o esforço dele em colaborar.

No entanto ele está sendo cabeça dura. Do jeito que ele fala parece que as pessoas vão começar a mandar patches os quais serão imediatamente inseridos no código e pronto "tá feito a cagada".

Eu sei que ele sabe como o sistema de mediação de código funciona, mas mesmo assim ele quer inventar o sistema dele. Dê uma olhada nos issues que eu abri, todos eles o @maurogeorge vem com uma resposta contra. E o que me irrita mesmo que nas respostas dele a primeira coisa que ele diz é que concorda comigo mas "sempre tem um mas" não acha viável fazer daquele jeito "por enquanto".

O "por enquanto" ou "deixar como tá" é outro cliché irritante dele. Tipo, "vc tá certo" "mas" "por enquanto" vamos "deixar como tá".

[israelst]

@drupalista-br,

Sim, o @maurogeorge é um ótimo profissional, e entendo que ninguém está aqui pra ofender.

Acho que a maior fonte dessa divergência é a geografia combinada com nossa ainda deficiência de nos comunicar como grupo. Explico.

Uma das coisas que decidimos por aqui, é que cobrir o código de testes está no topo da lista de prioridades. Nessa direção, não faz sentido mergear código sem testes. Mas isso não quer dizer, absolutamente, que essa deve ser a sua prioridade também, só quer dizer que código sem teste não vai pro repositório principal.

Eu dou o maior valor ao que você está fazendo e acredito que muita coisa vai ser aproveitada, por isso, mesmo que você não concorde com a nossa prioridade e nossa cabeça dura em relação aos testes, queria que você continuasse por perto dando suas sugestões e codando do seu jeito. Vamos nos encontrar lá na frente.

Vamos nos encontrar no FISL?

[drupalista-br]

@israelst

Acho que a maior fonte dessa divergência é a geografia combinada com nossa ainda deficiência de nos comunicar como grupo

A geografia não deveria ser um problema, pois encurtar distâncias é a função da internet.

Uma das coisas que decidimos por aqui, é que cobrir o código de testes está no topo da lista de prioridades. Nessa direção, não faz sentido mergear código sem testes.

Primeiramente, o código de testes também precisa ser contribuido, pois só decidir que testes é a prioridade das prioridades não é produtivo, não é mesmo?

Uma vez que os administradores do repositório criam especificações, o segundo passo é publicar a decisão juntamente com as especificações a serem seguidas. Então porque não colocar essas informações na página de Download do boletophp.com.br.

---

Nevertheless, eu fiz várias autalizações na versão OO bem como criei um framework de unit tests usando o Simpletests.
Este é o pull request #24

Atualizei o README - https://github.com/drupalista-br/Boleto/blob/1.x-dev/README.md