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