Ciao a tutti.
Ho una domanda sulla gestione delle versioni di ruby che per me, che
provengo dal mondo .NET, abbastanza “particolare”.
Il dubbio nato da qui:
nel file .rvmrc si fa esplicito riferimento alla versione 1.9.2-p136.
Sul mio laptop ho installato la p180 e quindi lo script mi dice di
installare la 136. Questo vuol dire che devo installarmi tutte le
varie versioni? Possibile che non ci sia un modo per non vincolarmi
cosi tanto ad una minor release (credo che il pXXX sia pi che altro
un bugfix).
Questa pratica mi sembra “strana” per il fatto che devo legare i miei
programmi ad una particolare build del runtime.
Il giorno 28 febbraio 2011 20:54, Emanuele DelBono < [email protected]> ha scritto:
installare la 136. Questo vuol dire che devo installarmi tutte le
varie versioni? Possibile che non ci sia un modo per non vincolarmi
cosi tanto ad una minor release (credo che il pXXX sia pi che altro
un bugfix).
Questa pratica mi sembra “strana” per il fatto che devo legare i miei
programmi ad una particolare build del runtime.
Ciao,
Al contrario, secondo me un’ottima pratica. In questo modo tu sei in
grado
di ricostruire perfettamente l’ambiente usato dallo sviluppatore
originale,
anche a distanza di anni. Inoltre, una pratica molto comune negli
ambienti
Java (ho visto progetti vincolati a Java 1.5.3… brrr). Cambiare
versione
di VM potrebbe essere un problema, chi ti garantisce che vada tutto
perfettamente?
Inoltre se ti gestisci da “solo” i server con Passenger, sei vincolato
ad
usare la versione di Ruby con cui hai compilato passenger.
ok per la versione ma qui non cambiato nemmeno il minor, o sbaglio ?
Se non cambia il minor RVM non installa altre versioni, usa sempre la
stessa.
con questa pratica nn si rischia di avere sulla stessa macchina un elevato
numero di versioni dell’interprete con conseguente confusione (e inutile
spreco di spazio disco) ?
Perch confusione? La versione giusta per ogni progetto viene selezionata
quando ci entri…
Sono d’accordo con te che si spreca tanto spazio disco, ma perfortuna
economico di questi tempi :P.
ok per la versione ma qui non cambiato nemmeno il minor, o sbaglio ?
con questa pratica nn si rischia di avere sulla stessa macchina un
elevato
numero di versioni dell’interprete con conseguente confusione (e inutile
spreco di spazio disco) ?
Venendo dal mondo Tcl, dove la stabilita` e backwards compatibility
sono molto importanti, devo dire che neanche io sono contentissimo di
questo aspetto di Ruby.
Se hai rvm, bundle, e N progetti, rischi di avere N versioni di vari
gem da seguire, aggiornare e controllare, senza un sistema
particolarmente buono per gestire gli update di funzionalita` e gli
update di sicurezza (nel senso che probabilmente devono avere due
corsie diverse).
E` un po’ mele e arance, ma se ho un sistema Debian, sono sicuro di
ricevere aggiornamenti di sicurezza per diversi anni per il sistema
installato.
Il giorno 01 marzo 2011 09:31, David W. [email protected] ha
scritto:
Venendo dal mondo Tcl, dove la stabilita` e backwards compatibility
sono molto importanti, devo dire che neanche io sono contentissimo di
questo aspetto di Ruby.
La comunit Ruby non ha molto interesse a fare aggiornamenti di
sicurezza,
ecc…
E’ fatta per la maggior parte da appassionati, per appassionati… per
cui
quasi nessuno ha interesse a mantere versioni particolarmente
“antiquate”.
E’ una comunit che innova ad un ritmo molto pi veloce rispetto ad altre,
e
in cui girano (per me) meno soldi.
Pagheresti per avere supporto?
Se hai rvm, bundle, e N progetti, rischi di avere N versioni di vari
gem da seguire, aggiornare e controllare, senza un sistema
particolarmente buono per gestire gli update di funzionalita` e gli
update di sicurezza (nel senso che probabilmente devono avere due
corsie diverse).
Hai perfettamente ragione. Rails stesso ne una conferma… spesso e
volentieri hanno “mischiato” update di sicurezza con nuove funzionalit,
causando non pochi casini.
E` un po’ mele e arance, ma se ho un sistema Debian, sono sicuro di
ricevere aggiornamenti di sicurezza per diversi anni per il sistema
installato.
Hai assolutamente ragione!
Ma spesso in Debian (e Ubuntu) si ritrovano versioni “vecchie” di
programmi
e librerie…
E` un po’ mele e arance, ma se ho un sistema Debian, sono sicuro di
ricevere aggiornamenti di sicurezza per diversi anni per il sistema
installato.
Hai assolutamente ragione!
Ma spesso in Debian (e Ubuntu) si ritrovano versioni “vecchie” di programmi
e librerie…
Sicuramente non ci sono soluzioni facili, ma e qualcosa a cui prestare attenzione. Ruby e sempre piu` usato, e i soldi, business,
ecc… stanno arrivando.
Un punto di partenza e prestare attenzione al major, minor e patch nelle versioni, per essere molto chiari su cosa e cambiato. Cioe`,
non va assolutamente introdotto qualcosa che cambia l’interfaccia in
modo non backwards compatible se si aumenta solo il patch level.
Da qualche parte c’e` un sito che spiega tutto questo ma non mi viene in
mente.
Un punto di partenza e prestare attenzione al major, minor e patch nelle versioni, per essere molto chiari su cosa e cambiato. Cioe`,
non va assolutamente introdotto qualcosa che cambia l’interfaccia in
modo non backwards compatible se si aumenta solo il patch level.
Da qualche parte c’e` un sito che spiega tutto questo ma non mi viene in mente.
Hanno fatto “confusione” anche per Rails 3.0.4, se vai a vedere i
commenti
nei post, anche io ho avuto un paio di test che fallivano.
Rispettare il semantic versioning differente da fare security fix per
le
versioni passate, per me sono due problemi molto, molto diversi. Non
trovi?
Hanno fatto “confusione” anche per Rails 3.0.4, se vai a vedere i commenti
nei post, anche io ho avuto un paio di test che fallivano.
Rispettare il semantic versioning differente da fare security fix per le
versioni passate, per me sono due problemi molto, molto diversi. Non trovi?
Certo che sono diversi, ma troppo spesso vengono trascurati tutti e
due nel mondo Ruby, andando un po’ a naso. Rails per lo meno presta
un po’ di attenzione a 2.X in termini di sicurezza.
La comunit Ruby non ha molto interesse a fare aggiornamenti di sicurezza,
ecc…
E’ fatta per la maggior parte da appassionati, per appassionati… per cui
quasi nessuno ha interesse a mantere versioni particolarmente “antiquate”.
E’ una comunit che innova ad un ritmo molto pi veloce rispetto ad altre, e
in cui girano (per me) meno soldi.
Pagheresti per avere supporto?
beh, i concetti alla base sono molto vicini alla “cattedrale ed il
bazaar”. alle
spalle di ruby non ci sono sicuramente (e fortunatamente) colossi
dell’IT come
IBM, Sun, etc…
E` un po’ mele e arance, ma se ho un sistema Debian, sono sicuro di
ricevere aggiornamenti di sicurezza per diversi anni per il sistema
installato.
Hai assolutamente ragione!
Ma spesso in Debian (e Ubuntu) si ritrovano versioni “vecchie” di programmi
e librerie…
e paradossalmente, non solo Debian gestita da appassionati, ma in
ambito
enterprise usata SOLO SE il sysadmin ha libert di movimento. in genere
viene
proposta RHEL perch offre supporto e certificazioni
Interessante, ho sempre cercato di comunicare ai miei colleghi/capi
che il pacchetto Ruby non e’ composto solo dalla feature X e Y del
linguaggio ma dal fatto che con esso accedi ad un ecosistema
decisamente accattivante.
