[Rio-pm] Release de modulo Beta no CPAN

breno oainikusama em gmail.com
Sexta Maio 23 07:22:17 PDT 2014 

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

Mais detalhes sobre a lista de discussão Rio-pm