[Rio-pm] Release de modulo Beta no CPAN

Aureliano Guedes guedes_1000 em hotmail.com
Sexta Maio 23 02:55:11 PDT 2014 

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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140523/e4e9e0a4/attachment-0001.html>
-------------- Próxima Parte ----------
_______________________________________________
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