[Rio-pm] Release de modulo Beta no CPAN

Quinta Maio 22 08:00:32 PDT 2014

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