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 : > 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 : > > 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 : > > > >> 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ódu
Re: [Rio-pm] Release de modulo Beta no CPAN
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 : > 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 : > >> 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
