Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico Samir Cury
hehehe, valeu a forca galera, vai nascer esse fim de semana entao.

Na real o modulo ja ate funciona (e pra mim, funciona bem
http://www.wiliam.com.au/content/upload/blog/worksonmymachine.jpg). Entao
vou deixar de lado o underline.

So tem umas coisas bizarras no codigo que nao pensei na hora que escrevi e
que poderiam ser otimizadas, mas dai e que disseram, nada impede de lancar
novas versoes com as correcoes. Vou ate deixar o TODO no POD.

Abs


2014-05-23 10:17 GMT-07:00 Bruno Buss :

> 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 :
>
> 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 :
>> > 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 :
>> >
>> >> 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" 
>> >> Enviado: 23 de Maio de 2014 01:37
>> >> Para: "Perl Mongers Rio de Janeiro" 
>> >> 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 :
>> >>
>> >> 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 

Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico Bruno Buss
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 :

> 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 :
> > 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 :
> >
> >> 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" 
> >> Enviado: 23 de Maio de 2014 01:37
> >> Para: "Perl Mongers Rio de Janeiro" 
> >> 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 :
> >>
> >> 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 inadvertidament

Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico Nuba Princigalli
Garu já deu a dica! O lance é "vai fondo, vai fondo, vai fondo, até que
iu!" ;)

Sobre como lidar com números de versão, sugiro ler também
http://semver.org/


On Fri, May 23, 2014, at 11:22 AM, breno wrote:
> 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 :
> > 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 :
> >
> >> 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" 
> >> Enviado: 23 de Maio de 2014 01:37
> >> Para: "Perl Mongers Rio de Janeiro" 
> >> 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 :
> >>
> >> 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 e

Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico breno
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 :
> 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 :
>
>> 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" 
>> Enviado: 23 de Maio de 2014 01:37
>> Para: "Perl Mongers Rio de Janeiro" 
>> 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 :
>>
>> 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 d

Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico Renato Santos
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 :

>  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" 
> Enviado: 23 de Maio de 2014 01:37
> Para: "Perl Mongers Rio de Janeiro" 
> 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 :
>
> 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 q

Re: [Rio-pm] Release de modulo Beta no CPAN

2014-05-23 Por tôpico Aureliano Guedes
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" 
Enviado: 23 de Maio de 2014 01:37
Para: "Perl Mongers Rio de Janeiro" 
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 :

> 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