Mathieu :
[…]
rails (1.1.6.5618, 1.1.6, 1.0.0)
Tout pareil, j’ai un 1.1.6.5618
Alors, il y a plusieurs choses :
- les 1.2RC* apparaissent en 1.1.6.r, r étant un numéro de changeset.
- DHH vient tout juste de rajouter dans 1.2RC1, une modif de boot.rb
qui fait que si on a RAILS_GEM_VERSION=‘1.1.6’ par exemple,
rails va chercher la dernière version en 1.1.6 par exemple 1.1.6.5618.
conséquence : pour les RC2, RC3… on n’a pas à modifier
RAILS_GEM_VERSION
dans config/environment.rb
Or ce mécanisme vient tout juste d’être rajouter (changeset 5616).
De deux choses l’une :
1/ On crée une nouvelle appli après avoir installé 1.2RC1.
RAILS_GEM_VERSION est toujours à ‘1.1.6’, mais comme on a le
bon boot.rb, on pourra passer tranquillement à RC2, RC3…
(sauf 1.2 bien sûr)
2/ On veut mettre à jour une appli <= 1.1.6 (c’est un peu le serpent qui
se mord la queue), comme le nouveau boot.rb vient avec 1.2RC1,
un rake rails:update ne mettra pas à jour avec le dernier boot.rb
=> il faut mettre RAILS_GEM_VERSION Ã 1.1.6.5618, faire
un rake rails:update, puis virer le .5618 de RAILS_GEM_VERSION.
Je sais pas si je suis clair.
Si on a une appli < 1.1.6 et qu’on met RAILS_GEM_VERSION
à 1.1.6, ça va passer à 1.1.6 et non 1.2RC1 car on a toujours l’ancien
boot.rb et un rake rails:update une fois en 1.1.6 ne va rien changer,
car 1.1.6 a toujours l’ancien boot.rb.
Remarque : rake rails:update ne met pas à jour config/routes.rb ni
app/controller/application.rb, donc si vous voulez bénéficier de
nouvelles configs par défaut comme la route avec :format ou
la clé de session avec le nom de l’appli, il faudra le rajouter
à la main (si vous créez une nouvelle appli 1.2RC1, il n’y
a évidemment rien à faire)
-- Jean-François.
