garu++ Samir: http://www.troll.me/images/the-chuck-norris/chuck-norris-approved-ship-it.jpg
2014-05-23 11:22 GMT-03:00 breno <oainikus...@gmail.com>: > Samir, lança logo o módulo que agora eu to curioso :D > > Não se prenda por "não tem testes", "não tá pronto", "não tá > perfeito", ou "o que vão pensar de mim". Lembre que não é estático e > que você sempre pode lançar outras versões depois - quantas vc quiser! > - corrigindo ou melhorando. Lembra também que só vai usar quem quiser. > > O próprio Tokuhiro Matsuno, um dos autores mais assíduos do CPAN, > criador de módulos como Test::Pretty, Minilla, HTML::Escape e tantos > outros, costuma lançar seus primeiros módulos sem testes ou > documentação, e vai melhorando gradativamente. O Ricardo Signes, > mantenedor do Perl e maior autor do CPAN com módulos como Dist::Zilla > CPAN::Mini, Email::Sender entre vários outros, é conhecido por lançar > módulos sem documentação na primeira versão, e ir melhorando nas > seguintes. Há até casos extremos que não concordo muito mas acontecem, > como a primeira versão do Mojo, que quando o sri lançou era só um > placeholder pra reservar o namespace! > > Não tenha medo de lançar seu código para o mundo. O pior que pode > acontecer é ninguém usar (nem você) ;-) > > go go go! Aperta o botão! Você vai ver que não é nada de mais e > rapidinho estará lançando um módulo atrás do outro :D > > > []s > > -b > > > > 2014-05-23 10:56 GMT-03:00 Renato Santos <renato.c...@gmail.com>: > > Eu não dou tanto valor pro número, > > > > a primeira versão pode ser a 10.02.56 que eu não vo ligar, desde que a > > proxima seja maior. > > > > e ai sim, entra o negocio de usar versões impares, tipo, 10.03_55 pra > > publicar algum pre-release e testar sob o cpan inteiro. > > > > > > > > > > 2014-05-23 6:55 GMT-03:00 Aureliano Guedes <guedes_1...@hotmail.com>: > > > >> De novo, posso esta falando besteira, me corrijam se eu tiver errado. > Mas > >> acho que 0.0.1 ou 0.01 nao seriam números de versões ridículos. Já > seriam > >> números de versões funcionais. > >> Parece que até você do 2.0 para o 2.9.9 são geralmente so otimizações e > >> correções de pequenos bugs ou revisão de acordo com a versão do perl > atual > >> se preciso, entao o 3.0 seria realmente implementações de novas > >> funcionalidades ou mesmo a exclusão de alguma outra já existente. > >> > >> --- Mensagem Original --- > >> > >> De: "Samir Cury" <samircu...@gmail.com> > >> Enviado: 23 de Maio de 2014 01:37 > >> Para: "Perl Mongers Rio de Janeiro" <rio-pm@pm.org> > >> Assunto: Re: [Rio-pm] Release de modulo Beta no CPAN > >> > >> Exato Breno, valeu pelos exemplos que dao um pouco mais de coragem de > >> subir o modulo. > >> > >> Essa e a ideia. Estou cozinhando esse modulo desde os fins de semana de > >> 2012 por nao ter testes decentes. Agora que tem estou procurando nao > deixar > >> o otimo ser inimigo do bom. "release early, release often" > >> > >> Vou por o aviso e tambem um numero de versao ridiculo (0.1.0 ou 0.01), > dai > >> fica obvio. > >> > >> Abs > >> > >> > >> 2014-05-22 8:00 GMT-07:00 breno <br...@rio.pm.org>: > >> > >> Samir, > >> > >> O método que Blabos e Cron indicaram está corretíssimo, mas costuma > >> ser mais usado quando você já tem uma versão pública estável. Por > >> exemplo, se seu módulo é Foo::Bar 1.03 e vc quer lançar uma versão > >> "trial", dê um número de versão 1.03_01, 1.03_02, assim por diante, e > >> ela será marcada como "trial" e só poderá ser instalada via caminho > >> explícito. Quando se tornar estável, vc sobe pra 1.04 e lança a versão > >> "estável". > >> > >> Se, por outro lado, este é o seu primeiro módulo e suas dúvidas estão > >> mais em torno de API ou se o módulo faz direito tudo que você quer, > >> você pode sempre colocar um aviso em letras garrafais no início da sua > >> documentação avisando que o módulo está em estágio alfa, beta, etc., > >> que a API pode mudar e que a pessoa deve usar sob sua própria conta e > >> risco. Por exemplo: > >> > >> https://metacpan.org/pod/Fey::ORM#EARLY-VERSION-WARNING > >> > >> https://metacpan.org/pod/Stepford#DESCRIPTION > >> > >> https://metacpan.org/pod/Debug::Client#DESCRIPTION > >> > >> Nenhum módulo nasce perfeito. Lance o seu logo! Se der errado você > >> sempre pode tomar uma cerveja e lançar outra versão :) > >> > >> []s > >> > >> -b > >> > >> > >> > >> > >> 2014-05-21 12:17 GMT-03:00 Samir Cury <samircu...@gmail.com>: > >> > Valeu mesmo pelas dicas Blabos. Esclareceu bastante tambem a funcao do > >> > underline. Vou tentar desse jeito entao pra validar o processo do > inicio > >> > ao > >> > fim antes de um release publico. Que bom saber que agora os > >> > procedimentos > >> > estao ainda melhores, vou dar um olhada no dzil. Estava ate agora > usando > >> > o > >> > que o Padre oferece, que para a Fase 1 e 2 deu certo, mas e bem capaz > >> > que > >> > precise de algo mais para criar a distribuicao que vai subir pro CPAN. > >> > > >> > Abs > >> > > >> > > >> > 2014-05-20 20:26 GMT-07:00 Blabos de Blebe <bla...@gmail.com>: > >> > > >> >> Ao colocar o underline na versão, vc evita que os instaladores usem > >> >> essa > >> >> versão inadvertidamente, embora ela ainda seja instalável se for > >> >> especificado o caminho completo para o pacote. > >> >> > >> >> Assim, você pode usar a infra-estrutura do cpan testers pra testar o > >> >> seu > >> >> módulo antes de um release público, sem prejudicar quem já está > usando > >> >> uma > >> >> versão estável do seu módulo. > >> >> > >> >> O Dist::Zilla não é uma unanimidade, embora eu o utilize na maioria > dos > >> >> meus módulos públicos ou privados. Eventualmente pode ser chato lidar > >> >> com > >> >> alguns bugs em edge cases, mas normalmente ele tira muito boiler > plate > >> >> da > >> >> sua frente. > >> >> > >> >> A vantagem do dzil é que ele encapsula o acesso a ferramentas de > várias > >> >> fases do processo de desenvolvimento, desde o startup do módulo até o > >> >> release no cpan. > >> >> > >> >> Eventualmente você pode dividir esse processo em algo como: > >> >> > >> >> 1) Fase 1: Fazer o bootstrap do seu pacote. > >> >> > >> >> Isso significa criar os diretórios padrão (/lib, /t, etc) bem como os > >> >> arquivos auxiliares. > >> >> > >> >> Além do dzil, um aplicativo que eu uso pra fazer o bootstrap dos meus > >> >> módulos é o https://metacpan.org/pod/Module::Starter > >> >> > >> >> Com ele você pode escolher qual builder você vai utilizar pra montar > o > >> >> seu > >> >> pacote. > >> >> > >> >> 2) Fase 2: code, code, code > >> >> > >> >> 3) Fase 3: Build > >> >> > >> >> No processo de build, uma peça de software é utilizada para juntar > tudo > >> >> que o seu pacote vai precisar para ser instalado em uma máquina > >> >> qualquer. > >> >> > >> >> Essa etapa pode ser baseada em vários builders como: > >> >> > >> >> https://metacpan.org/pod/ExtUtils::MakeMaker > >> >> https://metacpan.org/pod/Module::Build > >> >> https://metacpan.org/pod/Module::Install > >> >> > >> >> Esses builders baseiam-se em arquivos perl (Makefile.PL, Build.PL, > etc) > >> >> para a partir de apontamentos que você faz, verificar as > dependências, > >> >> criar > >> >> o Makefile e seus alvos,gerar o .tar.gz entre outras coisas > necessárias > >> >> para > >> >> tornar o seu módulo instalável. > >> >> > >> >> Quando vc instala um módulo manualmente, normalmente o processo é: > >> >> > >> >> a) Baixar e descompactar o .tar.gz > >> >> b) perl Makefile.PL (ou perl Build.PL). Isso vai criar um arquivo > >> >> Makefile > >> >> adaptado pra sua máquina. > >> >> c) make. Isso vai fazer o build do seu módulo, eventualmente > compilando > >> >> XS, se for o caso, etc > >> >> d) make test. Lê o Makefile para executar os testes do seu módulo. > >> >> e) make install > >> >> > >> >> Quando você cria um módulo, para montar o .tar.gz normalmente você > faz: > >> >> > >> >> a) perl Makefile.PL (ou perl Build.PL). Isso vai criar um arquivo > >> >> Makefile > >> >> adaptado pra sua máquina. > >> >> b) make manifest. Isso vai criar uma lista com todos os arquivos que > >> >> precisam ser distribuídos dentro do seu .tar.gz > >> >> c) make dist. Isso vai criar um .tar.gz do seu módulo, dentro do > qual, > >> >> haverá um Makefile.PL (ou Build.PL), e *não* um Makefile. > >> >> > >> >> Os arquivos *.PL precisam ser executados no momento da instalação > para > >> >> que > >> >> o Makefile seja montado de acordo com a máquina onde ele está sendo > >> >> instalado e não de acordo com a máquina onde o módulo foi criado. > >> >> > >> >> > >> >> 4) Release. > >> >> > >> >> Consiste em enviar o seu módulo para o CPAN. > >> >> > >> >> *** > >> >> > >> >> O Module::Make eu vou desconsiderar, porque ele só tem uma versão > >> >> antiga > >> >> lançada e nenhum outro módulo do cpan o utiliza > >> >> (https://metacpan.org/requires/distribution/Module-Make?sort=[[2,1]] > ). > >> >> > >> >> *** > >> >> > >> >> Com o dzil você tem uma ferramenta, que em conjunto com plugins cobre > >> >> todas as etapas listadas acima e mais algumas outras, como integração > >> >> com o > >> >> seu sistema de controle de versão e simplificação da criação de POD, > >> >> por > >> >> exemplo. > >> >> > >> >> Já se você preferir fazer sem ele, você pode fazer tudo manualmente, > ou > >> >> usar qualquer dessas ferramentas citadas acima pra cobrir uma fase ou > >> >> outra, > >> >> ou ainda combiná-las entre si. > >> >> > >> >> Eu particularmente tenho módulos que usam o dzil > >> >> (https://github.com/blabos/Dancer2-Plugin-Paginator) e módulos que > não > >> >> usam > >> >> (https://github.com/blabos/Paginator-Lite). > >> >> > >> >> E quando não uso, tenho preferência por criar o módulo com o > >> >> Module::Starter (não confundir com > >> >> https://metacpan.org/pod/Module::Start) > >> >> usando como builder o Module::Install. > >> >> > >> >> *** > >> >> > >> >> Finalizando, só preste atenção no que você deseja fazer e escolha a > >> >> ferramenta que achar mais adequada, tendo em mente que embora seja > >> >> relativamente simples criar um módulo e botar no CPAN, há várias > etapas > >> >> envolvidas, que na maioria das vezes já são até instintivas, mas que > se > >> >> você > >> >> misturar as coisas, pode dar a maior confusão. > >> >> > >> >> []'s > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 2014-05-20 16:12 GMT-03:00 Aureliano Guedes <guedes_1...@hotmail.com > >: > >> >> > >> >>> >Sim, passei o olho nisso, mas meio que ignorei pois o mesmo usa > >> >>> > Dist::Zilla e lembro que os 2 metodos mais recomendados eram > >> >>> > >Module::Build > >> >>> > e Module::Make. > >> >>> > >> >>> Posso estar enganado, mas esses 'eram' os mais recomendados. O > >> >>> Dist::Zilla é mais recente porem creio que seja o melhor e > atualmente > >> >>> o > >> >>> 'mais recomendado'. > >> >>> > >> >>> ________________________________ > >> >>> Date: Tue, 20 May 2014 11:52:43 -0700 > >> >>> From: samircu...@gmail.com > >> >>> To: rio-pm@pm.org > >> >>> Subject: Re: [Rio-pm] Release de modulo Beta no CPAN > >> >>> > >> >>> > >> >>> Sim, passei o olho nisso, mas meio que ignorei pois o mesmo usa > >> >>> Dist::Zilla e lembro que os 2 metodos mais recomendados eram > >> >>> Module::Build e > >> >>> Module::Make. > >> >>> > >> >>> Lendo melhor, parece que rola uma discussao entre usar as flags > >> >>> oficiais > >> >>> do CPAN ou _ na versao. Hum. > >> >>> > >> >>> Meio tosco que as flags oficiais do CPAN sao mais inuteis do que um > _ > >> >>> na > >> >>> versao. Mas o argumento da confusao no metacpan faz sentido. > >> >>> > >> >>> De qualquer jeito quando visito a pagina um modulo nao vejo a flag > la > >> >>> : > >> >>> > >> >>> http://search.cpan.org/~ingy/Module-Make-0.01/lib/Module/Make.pm > >> >>> > >> >>> Entao de repente o melhor e fazer como o "ingy" e colocar uma nota > no > >> >>> POD. > >> >>> > >> >>> Abs > >> >>> > >> >>> > >> >>> 2014-05-20 11:39 GMT-07:00 Renato Santos <renato.c...@gmail.com>: > >> >>> > >> >>> * > >> >>> > >> >>> > http://blogs.perl.org/users/oliver_gorwits/2011/10/releasing-trialdevbeta-versions-with-distzilla.html > >> >>> > >> >>> #fastreply > >> >>> > >> >>> > >> >>> 2014-05-20 15:35 GMT-03:00 Samir Cury <samircu...@gmail.com>: > >> >>> > >> >>> Pessoal, > >> >>> > >> >>> Outro dia na lista, li alguem dizendo : manda pro CPAN logo como > >> >>> "beta" > >> >>> > >> >>> Como estou no passo intermediario para o meu primeiro modulo > >> >>> "decente", > >> >>> com testes e tudo mais, talvez nao tenha visto essa opcao ainda. > >> >>> Pesquisando > >> >>> um pouco esbarrei com todas essas definicoes : > >> >>> > >> >>> http://search.cpan.org/dlsip?bpmOp > >> >>> > >> >>> Ja que o modulo funciona, esta documentado e passa no "prove", achei > >> >>> interessante subir como beta, e lancar novas releases quando fizer > >> >>> mais > >> >>> refatoracoes. > >> >>> > >> >>> Enfim. Queria confirmar com a galera que ja trilhou este caminho, > que > >> >>> quando eu for realmente subir o modulo vou ter a opcao de marcar > como > >> >>> beta. > >> >>> > >> >>> Pra quem estiver curioso este e o modulo : > >> >>> > >> >>> https://github.com/samircury/HTCondor--Queue--Parser > >> >>> > >> >>> Abs, > >> >>> Samir > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Rio-pm mailing list > >> >>> Rio-pm@pm.org > >> >>> http://mail.pm.org/mailman/listinfo/rio-pm > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Saravá, > >> >>> Renato CRON > >> >>> http://www.renatocron.com/blog/ > >> >>> @renato_cron > >> >>> > >> >>> _______________________________________________ > >> >>> Rio-pm mailing list > >> >>> Rio-pm@pm.org > >> >>> http://mail.pm.org/mailman/listinfo/rio-pm > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ Rio-pm mailing list > >> >>> Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm > >> >>> > >> >>> _______________________________________________ > >> >>> Rio-pm mailing list > >> >>> Rio-pm@pm.org > >> >>> http://mail.pm.org/mailman/listinfo/rio-pm > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> Rio-pm mailing list > >> >> Rio-pm@pm.org > >> >> http://mail.pm.org/mailman/listinfo/rio-pm > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rio-pm mailing list > >> > Rio-pm@pm.org > >> > http://mail.pm.org/mailman/listinfo/rio-pm > >> _______________________________________________ > >> Rio-pm mailing list > >> Rio-pm@pm.org > >> http://mail.pm.org/mailman/listinfo/rio-pm > >> > >> > >> > >> _______________________________________________ > >> Rio-pm mailing list > >> Rio-pm@pm.org > >> http://mail.pm.org/mailman/listinfo/rio-pm > > > > > > > > > > -- > > Saravá, > > Renato CRON > > http://www.renatocron.com/blog/ > > @renato_cron > > > > _______________________________________________ > > Rio-pm mailing list > > Rio-pm@pm.org > > http://mail.pm.org/mailman/listinfo/rio-pm > _______________________________________________ > Rio-pm mailing list > Rio-pm@pm.org > http://mail.pm.org/mailman/listinfo/rio-pm > -- Bruno C. Buss http://www.brunobuss.net
_______________________________________________ Rio-pm mailing list Rio-pm@pm.org http://mail.pm.org/mailman/listinfo/rio-pm