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 <[email protected]>: > 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 <[email protected]>: > > 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 <[email protected]>: > > > >> 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 <[email protected]>: > >> > >>> >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: [email protected] > >>> To: [email protected] > >>> 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 <[email protected]>: > >>> > >>> * > >>> > 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 <[email protected]>: > >>> > >>> 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 > >>> [email protected] > >>> http://mail.pm.org/mailman/listinfo/rio-pm > >>> > >>> > >>> > >>> > >>> -- > >>> Saravá, > >>> Renato CRON > >>> http://www.renatocron.com/blog/ > >>> @renato_cron > >>> > >>> _______________________________________________ > >>> Rio-pm mailing list > >>> [email protected] > >>> http://mail.pm.org/mailman/listinfo/rio-pm > >>> > >>> > >>> > >>> _______________________________________________ Rio-pm mailing list > >>> [email protected] http://mail.pm.org/mailman/listinfo/rio-pm > >>> > >>> _______________________________________________ > >>> Rio-pm mailing list > >>> [email protected] > >>> http://mail.pm.org/mailman/listinfo/rio-pm > >> > >> > >> > >> _______________________________________________ > >> Rio-pm mailing list > >> [email protected] > >> http://mail.pm.org/mailman/listinfo/rio-pm > > > > > > > > _______________________________________________ > > Rio-pm mailing list > > [email protected] > > http://mail.pm.org/mailman/listinfo/rio-pm > _______________________________________________ > Rio-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/rio-pm >
_______________________________________________ Rio-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/rio-pm
