Re: [Rio-pm] Release de modulo Beta no CPAN
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
Re: [Rio-pm] Release de modulo Beta no CPAN
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
Re: [Rio-pm] Release de modulo Beta no CPAN
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
Re: [Rio-pm] Release de modulo Beta no CPAN
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
Re: [Rio-pm] Release de modulo Beta no CPAN
. 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 http://twitter.com/#%21/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] Release de modulo Beta no CPAN
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
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 http://twitter.com/#!/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
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. 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 CRONhttp://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
Re: [Rio-pm] Release de modulo Beta no CPAN
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
