São jóias github menos estável do que gemas rubyforge?

Question

Na esta questão , eu mencionei a minha suposição de que gemas rubyforge são mais oficial, autoritário e estável do que garfos github. Uma das pessoas que responderam à minha pergunta disse que minha suposição pode não ser precisa.

O que você observa? Que as pessoas usam github para liberar cedo e liberar muitas vezes, apenas a colocar versões estáveis ??em rubyforge, ou que as pessoas liberam menos frequentemente em rubyforge por outras razões (por exemplo rubyforge ser mais de um aborrecimento)?

Atualizar : Esta pergunta é um pouco discutível agora. gemas Github são extinta, e gemas rubyforge vão ser movidos para rubygems.org.

Answer 1

Não há diferença, tanto quanto eu posso dizer.

Há uma enorme variedade em termos de qualidade / estabilidade de gemas de ambas as fontes. Alguns são rocha sólida, outros são de qualidade pré-alfa.

Ela realmente depende do próprio projeto jóia.

Dito isso, porém, o modelo github se presta a sua vez mais rápida em torno de questões. É muito mais fácil de desembolsar um projeto, corrigir um bug, e enviá-lo de volta para ser incluído na fonte original. Assim, pelo menos nos projetos populares, os erros são corrigidos mais rapidamente. Então, talvez, que ajuda os projectos amadurecem mais rápido, mas eu não sei.

Answer 2

O que eu notei é uma qualidade decrescente de GEM lançado via GitHub comparação com a qualidade geral do GEMS na RubyForge.

IMHO há pelo menos dois grandes explicação para este comportamento:

-

Antes de GitHub a 99% dos Rubyist foi Subversion-dependente. Você pode dizer o que quiser sobre o Subversion, mas é definitivamente mais fácil de usar em comparação com Git e todo mundo está ciente do trunk / tags / layout de ramos. Então as pessoas começaram a se mudar para Git. Apenas uma fatia super-limitado de usuários do Subversion começaram a usar Git com o nível de conhecimento que deve exigir e, o que eu notei, é que as pessoas começaram a se esqueceu de tags.

Era uma vez havia tags. Em subversão pessoas foram usadas para liberar nova versão baseada em tags específicas para que você possa facilmente detectar qual versão você instalou e que foi o ramo estável.

Hoje em dia eu vejo toneladas de bibliotecas sempre em desenvolvimento no branch master Git. Nenhuma tag, sem ramos estáveis. Em geral, quando as bibliotecas onde liberados via RubyForge houve um maior nível de atenção para a etapa de implantação.

-

GitHub faz a etapa de publicação mais um aborrecimento. Dito isto, você pode facilmente publicar uma nova GEM simplesmente empurrando o gemspec em seu repositório.

Na minha opinião essa simplicidade pode pode levar a uma menor qualidade. Mais menos qualificados desenvolvido começou a distribuir GEMS porque é tão fácil como a geração de um novo projeto com Joalheiro (ou uma biblioteca similar) e empurrando um repositório git. Eles não sabiam muito mais sobre o gerenciamento de versão, compatibilidade com versões anteriores, colisões de libertação, manutenção liberação.

Muitas vezes me deparei com um bibliotecas inacabadas embalados como um GEM só porque o desenvolvedor esqueceu de remota do arquivo .gemspec. Cada commit causado um novo GEM para ser construído sem aparente coerência e consistência.

Eu sou absolutamente a favor da prática "liberar muitas vezes", mas quando faz sentido. Git fornece um excelente suporte ramo, você não precisa encher o branch master com toneladas de commits independentes e liberando peça inacabada de código que você chama bibliotecas.

-

Por último, mas não menos importante, o que provavelmente mais odeio é a duplicação ilimitada do mesmo GEM. Quando RubyForge era a fonte GEM inconteste, era muito fácil de encontrar e instalar um novo projeto.

IMHO, GitHub introduzida uma camada desnecessária de complexidade. Primeiro, você tem GEM ambos disponíveis via rubyforge como mygem e via GitHub como username-mygem. Muitas vezes você precisa gastar tempo para descobrir o que GEM é a mais atualizada e segura o desenvolvimento mestre.

Além disso, alguns GEM popular, não foi mais atualizado sobre RubyForge e muitas pessoas continuam a usá-los só porque RubyGems não notificá-lo sobre novas versões. Fácil de entender, se você instalou liberação coolgem 1.2.4 e a mesma biblioteca está agora disponível como superusuário-coolgem (versão 2.0), RubyGems não é suficiente inteligente para dizer-lhe uma nova atualização está disponível.

-

Agora é tempo para um aviso.

Eu não estou dizendo usuários GitHub produz GEMS de baixa qualidade em comparação com RubyForge. Eu sou um usuário GitHub e antes eu era um usuário RubyForge também. Milhares de GEMS migraram com sucesso de RubyForge para GitHub sem deixar o usuário final no "que um" limbo.

O melhor exemplo Rails, mas posso citar muitas outras pedras preciosas, incluindo (mas não limitado a) Capistrano, Hpricot, RedCloth ... Todas essas bibliotecas são agora hospedado no GitHub e se você olhar atentamente para eles você pode facilmente reconhecer o mesmo nível de qualidade como antes.

Por último, mas não menos importante, todas as bibliotecas continuam a ser liberado via RubyForge como a fonte principal para que você não precisa reconfigurar seu ambiente para detectar se instalar trilhos-rails ou rails.

Além disso, o usuário final não é afetado pelas decisões de desenvolvimento. Tome Capistrano por exemplo. Um golpele de meses atrás Jamis anunciou o fim de seu compromisso com o desenvolvimento. A comunidade se encarregou do desenvolvimento e mudou-se o repositório mestre de Jamis / Capistrano Capistrano / Capistrano. O que aconteceria se o GEM foi lançado como Jamis-Capistrano? Todos os usuários teriam de mudar para o novo GEM eo novo repositório com monte de problemas.

Este cenário não arised porque RubyForge foi e continuará a ser o principal centro de entrega Capistrano.

-

Em conclusão, eu, infelizmente, percebe uma diminuição global da qualidade GEM causada principalmente por mais pessoas que se aproximam Ruby e RubyGems sem o necessário nível de conhecimento. O mesmo se aplica a um grande número de Rails plugins.

GitHub não pode ser rotulado como o culpado. Quando as coisas complexas se tornam mais fácil e mais pessoas abordá-los sem um conhecimento subjacente, é normal que a qualidade pode diminuir porque a complexidade é um processo de seleção natural.

De qualquer forma, ainda há um excelente nível de qualidade na comunidade Ruby. É incrível ver como desenvolvedores Ruby estão comprometidos com o teste de unidade e de outros hábitos de programação profissional.

Answer 3

Provavelmente menos estável e um pouco mais atualizado :) -r

Answer 4

para responder à sua pergunta, finalmente:. Ambos os recursos que você mencionou (rubyforge, github) são agora obsoletos, uma vez gemcutter é o novo eo único lugar para rubygems

Gemcutter é o novo Oficial Anfitrião RubyGem Padrão: http: //www.rubyinside. com /-gemcutter-o-new-oficial-default-rubygem-host-2659.html