Sono gemme GitHub meno stabile di gemme RubyForge?

Question

questa domanda , ho detto la mia ipotesi che le pietre preziose RubyForge sono più ufficiale, autorevole e stabile di forcelle Github. Una delle persone che hanno risposto alla mia domanda ha detto che la mia ipotesi potrebbe non essere accurata.

Cosa avete osservato? Le persone usano github per rilasciare presto e rilascia spesso, solo mettendo versioni stabili su RubyForge, o la gente rilasciano meno spesso su RubyForge per altri motivi (ad esempio RubyForge essendo più di una seccatura)?

Aggiorna : Questa domanda è un po 'discutibile ora. gemme Github sono defunta , e noreferrer gemme RubyForge stanno per essere spostati in rubygems.org.

Answer 1

Nessuna differenza per quanto posso dire.

C'è una vasta gamma in termini di qualità / stabilità delle gemme provenienti da entrambe le fonti. Alcuni sono roccia solida, gli altri sono di qualità pre-alpha.

In realtà dipende il progetto gemma stessa.

Detto questo, però, il modello github si presta a più rapida girarsi su questioni. E 'molto più facile a sborsare un progetto, correggere un bug, e inviare di nuovo a essere incluso nella fonte originale. Così almeno sui progetti popolari, bug si fissa più veloce. Così forse che aiuta i progetti maturi più veloce, ma non so.

Answer 2

Quello che ho notato è una qualità decrescente di GEM rilasciato via GitHub rispetto alla qualità complessiva delle gemme a RubyForge.

IMHO ci sono almeno due grandi spiegazione per questo comportamento:

-

Prima di GitHub il 99% dei Rubyist era Subversion-dipendente. Si può dire quello che volete su Subversion, ma è sicuramente più facile da usare rispetto a Git e tutti sono a conoscenza del / tag / layout di tronco rami. Poi la gente ha cominciato a muoversi a Git. Solo un super-limitata fetta di utenti Subversion ha iniziato ad utilizzare Git con il livello di conoscenza che dovrebbe richiedere e, quello che ho notato, è che la gente ha iniziato a dimenticato di tag.

Una volta c'erano i tag. In Subversion persone sono stati usati per rilasciare nuova versione basata su tag specifici in modo che si può facilmente rilevare quale versione è stato installato e che era il ramo stabile.

Oggi vedo tonnellate di librerie sempre in fase di sviluppo nel master ramo Git. Nessun tag, senza rami stabili. In generale, quando le biblioteche dove rilasciato tramite RubyForge si è registrato un più elevato livello di attenzione alla fase di distribuzione.

-

GitHub rende la fase di pubblicazione non è più una seccatura. Detto questo, si può facilmente pubblicare un nuovo GEM semplicemente premendo il gemspec nel repository.

A mio parere questa semplicità può può portare ad una qualità inferiore. Altro meno qualificati sviluppato iniziato a distribuire GEMS perché è facile come generare un nuovo progetto con Gioielliere (o una libreria simile) e spingendo un repository git. Non sapevano molto di più sulla gestione dei rilasci, la compatibilità a ritroso, dossi di rilascio, la manutenzione di rilascio.

Spesso mi sono imbattuto in un librerie non finiti confezionati come GEM solo perché lo sviluppatore ha dimenticato di distanza il file .gemspec. Ogni commit ha causato un nuovo gioiello di essere costruita con coerenza senza apparente e consistenza.

Sono assolutamente a favore del "rilascio spesso" pratica, ma quando ha senso. Git fornisce un ottimo supporto ramo, non è necessario ingombrare ramo principale con tonnellate di commit non collegati e rilasciando Partitura incompiuta di codice che si chiama le librerie.

-

Ultimo ma non meno importante, quello che probabilmente io odio di più è la duplicazione illimitata dello stesso GEM. Quando RubyForge era la fonte GEM incontrastato, è stato abbastanza facile da trovare e installare un nuovo progetto.

IMHO, GitHub ha introdotto un inutile strato di complessità. In primo luogo, si dispone di GEM entrambi disponibili tramite RubyForge come mygem e via GitHub come username-mygem. Spesso è necessario spendere tempo per capire quale GEM è la più aggiornata e mantiene lo sviluppo master.

Inoltre, alcuni GEM popolare non era più aggiornato RubyForge e molte persone continua ad usarli solo perché RubyGems non notifica sulle nuove versioni. Facile da capire, se è stato installato coolgem rilasciare 1.2.4 e la stessa libreria è ora disponibile come superutente-coolgem (versione 2.0), RubyGems non è abbastanza intelligente per dirvi un nuovo aggiornamento è disponibile.

-

Ora è il momento per una dichiarazione di non responsabilità.

Non sto dicendo che gli utenti GitHub produce GEMS scadente rispetto a RubyForge. Sono un utente GitHub e prima ero un utente RubyForge pure. Migliaia di GEMS migrati con successo da RubyForge a GitHub senza lasciare l'utente finale nella "quale" limbo.

L'esempio migliore Rails, ma posso citare molti altri tesori tra cui (ma non solo) Capistrano, Hpricot, RedCloth ... Tutti queste librerie sono ora ospitato su GitHub e se si guarda con attenzione a loro si può facilmente riconoscere il stesso livello di qualità come prima.

Ultimo ma non meno importante, tutte queste librerie continuano ad essere rilasciato tramite RubyForge come fonte master in modo che non è necessario riconfigurare il proprio ambiente per rilevare se installare rotaie-rotaie o binari.

Inoltre, l'utente finale non è influenzato da decisioni di sviluppo. Prendere Capistrano per esempio. Un colpo di statoLe di mesi fa Jamis ha annunciato la fine del suo impegno per lo sviluppo. La comunità si è incaricato dello sviluppo e si è trasferito il repository principale da Jamis / Capistrano a Capistrano / Capistrano. Che cosa accadrebbe se la GEM è stato rilasciato come Jamis-Capistrano? Tutti gli utenti avrebbero dovuto passare al nuovo GEM e il nuovo repository con sacco di problemi.

Questo scenario non arised perché RubyForge è stato e continuerà ad essere il principale hub di consegna Capistrano.

-

In conclusione, si accorge purtroppo una diminuzione complessiva di qualità GEM causato principalmente da più persone si avvicinano Ruby e RubyGems, senza il necessario livello di conoscenza. Lo stesso si applica ad un gran numero di Rails plugin.

GitHub non può essere etichettato come il colpevole. Quando le cose diventano più complesse facile e più persone li avvicinano, senza una conoscenza di base, è normale che la qualità può diminuire perché la complessità è un processo di selezione naturale.

In ogni caso, c'è ancora un ottimo livello di qualità nella comunità di Ruby. E 'sorprendente vedere come sviluppatori Ruby sono impegnati a test di unità e di altre abitudini di programmazione professionale.

Answer 3

Probabilmente meno stabile e leggermente più aggiornati :) -r

Answer 4

per rispondere alla tua domanda, infine:. Sia delle risorse che hai citato (RubyForge, GitHub) sono ormai obsoleto, in quanto Gemcutter è il luogo nuovo e solo per rubygems

Gemcutter è il nuovo default Ufficiale rubygem Host: http: //www.rubyinside. com / Gemcutter-è-il-nuovo-ufficiale-default-rubygem-host-2659.html