[Rio-pm] Release de modulo Beta no CPAN
Bruno Buss
bruno.buss em gmail.com
Sexta Maio 23 10:17:11 PDT 2014
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 <oainikusama em 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.cron em 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_1000 em 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" <samircurys em gmail.com>
> >> Enviado: 23 de Maio de 2014 01:37
> >> Para: "Perl Mongers Rio de Janeiro" <rio-pm em 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 <breno em 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 <samircurys em 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 <blabos em 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_1000 em 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: samircurys em gmail.com
> >> >>> To: rio-pm em 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.cron em 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 <samircurys em 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 em 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 em pm.org
> >> >>> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________ Rio-pm mailing list
> >> >>> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>>
> >> >>> _______________________________________________
> >> >>> Rio-pm mailing list
> >> >>> Rio-pm em pm.org
> >> >>> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Rio-pm mailing list
> >> >> Rio-pm em pm.org
> >> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Rio-pm mailing list
> >> > Rio-pm em pm.org
> >> > http://mail.pm.org/mailman/listinfo/rio-pm
> >> _______________________________________________
> >> Rio-pm mailing list
> >> Rio-pm em pm.org
> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >>
> >>
> >>
> >> _______________________________________________
> >> Rio-pm mailing list
> >> Rio-pm em 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 em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
--
Bruno C. Buss
http://www.brunobuss.net
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140523/91730822/attachment-0001.html>
Mais detalhes sobre a lista de discussão Rio-pm