… in genere aggiornate i vostri progetti?
Cosi’ facendo si rischia che l’applicazione non funzioni piu’ perche’
costruita utiizzando una certa versione di rails che poi risulta non
piu’ compatibile con la nuova.
Pero’ spesso puo’ capitare di doverci mettere le mani per modifiche ecc.
Allora cosa fare? Fissare la versione di rails nel Gemfile?
Cosi’ facendo alla fine ci si ritrova con non so quante versioni di
rails sul disco.
Che metodo utilizzate?
Ciao!
Penso che aggiornare o non aggiornare sia una scelta imposta da come
viene gestito il progetto e dalle risorse disponibili.
Io, prima di andare online, fisso sempre le versioni di tutte le gemme
utilizzate in un progetto. Mi sembra una pratica conveniente.
Ciao,
Silvano
2011/6/12 Mauro [email protected]:
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Considera l’ambiente prima di stampare questa email. Be a total user
rather than a complete waster.
. . . Silvano S. . . .
email: [email protected]
site: http://www.sistrall.it
2011/6/12 Silvano S. [email protected]:
Ciao!
Penso che aggiornare o non aggiornare sia una scelta imposta da come
viene gestito il progetto e dalle risorse disponibili.Io, prima di andare online, fisso sempre le versioni di tutte le gemme
utilizzate in un progetto. Mi sembra una pratica conveniente.
Si ma poi se dovessi rimettere la mani sul progetto devi tenere la
versione che hai fissato e cosi’ per tutti i progetti, quindi alla
fine ti ritrovi con un certo numero di versioni di rails, con tutte le
gem dipendenti, sul disco che puo’ non essere un problema, se pero’
hai molti progetti ognuno dipendente da una versione diversa di rails
puo’ essere noioso.
Normalmente aggiorno tutte le applicazioni in mia gestione ogni qual
volta viene rilasciata una nuova release.
Di norma, a seconda della versione, attendo un arco di tempo
necessario ad evitare Upgrade a catena dovuti a bug identificati solo
una volta che la versione esce mainstream.
Tipicamente aggiorno:
- una bugfix release entro una settimana
- una minor release entro un mese
- una major release entro due mesi
Non tengo mai indietro applicazioni a versioni datate, anche se si
tratta di progetti su cui non sto correntemente lavorando, poich non
appena torner a metterci mano so che lavorare con una versione di
rails vecchia comporta spesso difficolt maggiore nella manutenzione.
Per esperienza, un Upgrade ad una mini o bugfix release richiese
spesso meno di mezza giornata, a patto di avere ovviamente una test
suite estesa.
– Simone
On Sunday, June 12, 2011, Mauro [email protected] wrote:
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
Le migration sono lleggermente cambiate ma restano per ora BC con le
versioni precedenti.
Riguardo la release 3.1, posso dirti che ho gi aggiornato due
applicazioni 3.0.7 alla 3.1 e non ci sono particolari complessit.
Il cambiamento maggiore riguarda adattare il codice 3.0 alla nuova
struttura degli asset in 3.1.
– Simone
On Sunday, June 12, 2011, Mauro [email protected] wrote:
roba.
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
2011/6/12 Simone C. [email protected]:
Normalmente aggiorno tutte le applicazioni in mia gestione ogni qual
volta viene rilasciata una nuova release.
Di norma, a seconda della versione, attendo un arco di tempo
necessario ad evitare Upgrade a catena dovuti a bug identificati solo
una volta che la versione esce mainstream.
Capito, la mia domanda nasceva dal fatto che mi sembra di notare
diversi cambiamenti nella prossima versione di rails la 3.1, tanto per
cominciare il codice nelle migration…anche se si tratta di poca
roba.
2011/6/12 Simone C. [email protected]:
Le migration sono lleggermente cambiate ma restano per ora BC con le
versioni precedenti.
Riguardo la release 3.1, posso dirti che ho gi aggiornato due
applicazioni 3.0.7 alla 3.1 e non ci sono particolari complessit.
Io ho provato a fare una app ex novo con rails 3.1, l’ultima versione
mi pare che sia la 3.1.rc4, le migrations non funzionano.
2011/6/12 Simone C. [email protected]:
Ti consiglio di riprovare, segnarti l’errore ed aprire un bug report.
E’ confermato anche da altri:
I rischi di usare una RC release 
On Sunday, June 12, 2011, Mauro [email protected] wrote:
2011/6/12 Simone C. [email protected]:
Ti consiglio di riprovare, segnarti l’errore ed aprire un bug report.
E’ confermato anche da altri:
Ruby on Rails — [ANN] Rails 3.1.0.rc4 has been released!
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
Ti consiglio di riprovare, segnarti l’errore ed aprire un bug report.
On Sunday, June 12, 2011, Mauro [email protected] wrote:
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
Certamente. Io pero in quel progetto usavo MongoDB quindi non ho avuto
modo di provare le migrazioni.
On Sunday, June 12, 2011, Mauro [email protected] wrote:
On 12 June 2011 19:12, Simone C. [email protected] wrote:
I rischi di usare una RC release
Beh anche tu, se mi dici che hai usato la 3.1, avrai usato una RC.
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
On 12 June 2011 19:12, Simone C. [email protected] wrote:
I rischi di usare una RC release
Beh anche tu, se mi dici che hai usato la 3.1, avrai usato una RC.
L’approccio di Simone mi pare sensato, se riesci a includere i minor
framework upgrade in cicli prefissati sei a cavallo, e ti semplifichi
la vita quando vuoi passare ad una major release.
Come Silvano anche noi fissiamo una lista di gems. versione di rails e
Ruby che usiamo.
Se l’applicazione e’ di una certa dimensione ed ha diverse dipendenze
(gems o plugin) passare ad una nuova major release di Rails e’ un task
non indifferente. Qua i test riducono da 10 giorni a 10 ore e riducono
anche la caduta precoce dei capelli 
Comunque stai per introdurre dei cambiamenti e credo sia un
investimento che vada valutato caso per caso.
Noi abbiamo un app molto grossa (~10K linee) che e’ rimasta bloccata
(per ragioni politiche) a rails 2.3.4 ma comunque nuovi moduli (sotto
forma di plugins) vengono sviluppati attivamente e sono coperti da
cucumber ed rspec. E’ noioso perche’ certi bugs sono stati risolti da
un pezzo, e ci sarebbero soluzioni a piccoli problemi ma non e’ la
fine del mondo.
Credo che framework upgrade (sia minor the major) vadano comunque
fatti presente al cliente, e magari pagati. Anche se si hanno suite di
test e’ possibile mancare qualcosa e generare piccoli bug che possono
frustrare il cliente e causare altro lavoro agli sviluppatori.
HTH
Enrico
2011/6/12 Simone C. [email protected]:
Certamente. Io pero in quel progetto usavo MongoDB quindi non ho avuto
modo di provare le migrazioni.
Ok 