Rails 1.2RC1 dispo!

Bonjour

Voir l’annonce officielle par DHH :

A noter 2 changements dans la configuration par défaut effectués sur
les applis fraîchement créés mais qui faudra rajouter à la main dans
des applis existantes :

  • dans routes.rb, une nouvelle route “générique” pour utiliser le
    paramètre :format :

map.connect ‘:controller/:action/:id.:format’

  • dans app/controller/application.rb : les cookies ont des clés
    de noms de session avec le nom de l’application dedans :

dans ApplicationController :

session :session_key => ‘_<%= app_name %>_session_id’

Pour toutes les nouvelles fonctionnalités, voir l’annonce de DHH.

sudo gem install rails --source http://gems.rubyonrails.org
–include-dependencies

-- Jean-François.

Toulours premier sur l’info jean Francois.

Je m’en doutait au vu des commits log de ce matin.

Aller vivement ce soir pour mettre a jur tout ca.

Merci Jean-François pour l’info !!!

On 11/23/06, Guillaume G. [email protected] wrote:

sudo gem install rails --source http://gems.rubyonrails.org

http://lists.rubyonrails.fr/mailman/listinfo/railsfrance


Mathieu Fosse

http://blog.kawooa.org
http://www.ziki.com/people/pointcom

Merci, jean-françois

Là par contre, je pige pas tout, il propose de lancer version
“boucher” et d’y aller à la machette en fonction des injures^Wwarnings
qui apparaîssent.

Y’a pas une ptite liste des depreciations ?


Deprecation

Since Rails 1.0 we’ve kept a stable, backward-compatible API, so your
apps can move to new releases without much work. Some of that API now
feels like our freshman 15 so we’re going on a diet to trim the fat.
Rails 1.2 deprecates a handful of features which now have superior
alternatives or are better suited as plugins.

Deprecation isn’t a threat, it’s a promise! These features will be
entirely gone in Rails 2.0. You can keep using them in 1.2, but you’ll
get a wag of the finger every time: look for unsightly deprecation
warnings in your test results and in your log files.

Treat your 1.0-era code to some modern style. To get started, just run
your tests and tend to the warnings.

Le 23/11/06, guillaume belleguic [email protected]
a
écrit :

Surement normal tant que la 1.2 finale n’est pas sortie.

bonjour,
Je suis sous windows (oui je sais), et impossible de mettre à jour
rails, il garde la version 1.1.6.
je lance la commande :

|gem install rails --source http://gems.rubyonrails.org --include-dependencies

C’est normal docteur
|

Mathieu FOSSE a écrit :

des applis existantes :
session :session_key => ‘_<%= app_name %>_session_id’


Guillaume G.


Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

Guillaume BELLEGUIC
LES ACCORDEURS DE RESEAUX
e-ngoma / Ker data
4, cours Kennedy
35000 Rennes

[email protected]
http://www.e-ngoma.net

tèl : +33 (0)299 33 87 48
fax : +33 (0)299 33 97 31

RCS Rennes 487 799 892


Oui c’est normal que la 1.2RC1 apparaisse en 1.1.6.
Chez moi la 1.2RC1 apparaît comme version 1.1.6.5618.

Tu peux vérifier chez toi en tapant la commande suivante :
$ gem search rails -l

Voilà ce que donne cette commande chez moi :

*** LOCAL GEMS ***
rails (1.1.6.5618, 1.1.6, 1.0.0)
Web-application framework with template engine, control-flow layer,
and ORM.

Mathieu

On 11/23/06, Frédéric Logier [email protected] wrote:

C’est normal docteur


Mathieu Fosse

http://blog.kawooa.org
http://www.ziki.com/people/pointcom

Le Jeu 23 novembre 2006 11:27, Jean-François a écrit :

  • 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.

Grumph
J’ai le droit de dire que c’est une très mauvaise solution si elle
fonctionne bien comme ça ?

Si je bloque une 1.1.6 j’attend d’avoir une 1.1.6, et éventuellement les
modifications très mineures (1.1.6.*) qui devraient logiquement ne
corriger que des aspects sécu ou des bugs critiques.

A quoi ça sert de bloquer des versions si en bloquant sur une version
stable (1.1.6) on se retrouve avec un gem de développement de la prochaine
version majeure ?
Pire, non seulement en bloquant sur une stable on se retrouve avec la
phase de développement de la prochaine version majeure, mais en plus on
n’aura pas la mise à jour quand cette prochaine version majeure passera en
stable.

C’est quand même totalement crétin comme fonctionnement. Ce n’est pas pour
rien que les béta publiques ont généralement le numéro de version de la
cible (ici 1.2.0) et pas de l’origine (ici 1.1.6).

Ce n’est pas avec ce genre de choses qu’on va rassurer ceux qui sont déjà
effrayés au niveau du support des mises à jours et du problème de
l’évolution continue.


Eric D.

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.

Ma poire :

  • dans app/controller/application.rb : les cookies ont des clés
    de noms de session avec le nom de l’application dedans :

dans ApplicationController :

session :session_key => ‘_<%= app_name %>_session_id’

oops, je suis con !

si vous générer une nouvelle appli 1.2RC1 ‘foo’ alors dans
ApplicationController, vous aurez cette ligne, sans rien à faire :

session :session_key => ‘_foo_session_id’

si vous voulez suivre la même convention dans votre appli déjÃ
existante ‘bar’, mettez :

session :session_key => ‘_bar_session_id’

-- Jean-François.

Eric :

  • 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.

Grumph
J’ai le droit de dire que c’est une très mauvaise solution si elle
fonctionne bien comme ça ?

J’attends qu’on me confirme que mon raisonnement est correct :slight_smile:

Si je bloque une 1.1.6 j’attend d’avoir une 1.1.6, et éventuellement les
modifications très mineures (1.1.6.*) qui devraient logiquement ne
corriger que des aspects sécu ou des bugs critiques.

A quoi ça sert de bloquer des versions si en bloquant sur une version
stable (1.1.6) on se retrouve avec un gem de développement de la prochaine
version majeure ?

Tes remarques se tiennent. Pour l’instant, pour des applis <= 1.1.6,
ça n’affecte pas, puisque le 1.1.6 a toujours l’ancien boot.rb

Mais pour le futur, pour des applis >= 1.2 et des futurs RC…

Pire, non seulement en bloquant sur une stable on se retrouve avec
la phase de développement de la prochaine version majeure,

De toute manière pour une appli en prod, il vaut mieux bloquer une
version de Rails dans vendor/

mais en plus on n’aura pas la mise à jour quand cette prochaine
version majeure passera en stable.

Remarque judicieuse :slight_smile:
Mais si on a un update de sécurité 1.1.6.1
rien n’empêche de mettre RAILS_GEM_VERSION à 1.1.6.1

(à vérifier qu’il ne chope pas un 1.1.6.5618… :slight_smile:

C’est quand même totalement crétin comme fonctionnement. Ce n’est
pas pour rien que les béta publiques ont généralement le numéro de
version de la cible (ici 1.2.0) et pas de l’origine (ici 1.1.6).

Mais je me trompe peut-être mais on ne doit pas pouvoir mettre
des noms de versions comme rails-1.2.0rc1 dans le système rubygems
c’est pour ça que DHH a utilisé cette ‘ruse’…

Ce n’est pas avec ce genre de choses qu’on va rassurer ceux qui
sont déjà effrayés au niveau du support des mises à jours et du problème
de l’évolution continue.

Tu devrais soulever la question sur Rails-Core.

РJean-Fran̤ois.

Eric :

Pire, non seulement en bloquant sur une stable on se retrouve avec
la phase de développement de la prochaine version majeure,

De toute manière pour une appli en prod, il vaut mieux bloquer une
version de Rails dans vendor/

Certes, mais disons que le RAILS_GEM_VERSION sert quand même
justement à éviter de se retrouver avec un gem tout nouveau à la place
d’une stable bien connue. Là la numérotation rend quasiment inutile
(et même négative) l’utilisation de cette constante.

C’est vrai.

J’étais aussi en train de penser qu’il n’y avait pas de 1.1.x.x avant,
les security fix de 1.1.4 étaient 1.1.5 et 1.1.6 et non 1.1.4.x

Donc si bugfix ou security fix de 1.1.6, logiquement ce serait
en 1.1.7 ?

C’est quand même totalement crétin comme fonctionnement. Ce n’est
pas pour rien que les béta publiques ont généralement le numéro de
version de la cible (ici 1.2.0) et pas de l’origine (ici 1.1.6).

Mais je me trompe peut-être mais on ne doit pas pouvoir mettre
des noms de versions comme rails-1.2.0rc1 dans le système rubygems
c’est pour ça que DHH a utilisé cette ‘ruse’…

Dans ces cas là on voit souvent des “.9”, par exemple numéroter la RC
1.1.99,

J’y ai pensé après, avoir 1.1.99.5618 ou 1.1.99.6128, c’est mieux.

ou alors faire une branche de dev en 1.3.x et une branche
stable en 1.4.x,

Je pensais après 1.0 qu’ils allaient faire 2 branches 1.1.x et 1.2.x
et finalement non.

ou alors faire un gem “rails-beta” séparé, ou alors à la base
simplement ne pas mettre les RC en mise à jour automatique
dans les dépots gem (mais en téléchargement manuel).

les RCs ne sont peut-être pas propagés à Rubyforge mais
à l’époque, celles de 1.0RC l’étaient (série 0.14.*). M’est
avis que la politique actuelle a changé, RCs uniquement
dispo sur gems.rubyonrails.org

Bref, ce ne sont pas les solutions qui manquent.

Tu devrais soulever la question sur Rails-Core.

Franchement ? pas le temps.
Et puis je serai très inquiet si personne ne remarque les défauts
d’un tel système (donc si personne ne lance le sujet pour moi).

Bah il est encore tôt aux Etats-Unis…

Reste aussi la possibilité que j’ai manqué une marche dans mon
raisonnement et que le problème est évité d’une manière ou
d’une autre.

Je vais quand même soulever la question sur Rails Core.

РJean-Fran̤ois.

Mathieu :

LÃ par contre, je pige pas tout, il propose de lancer version
“boucher” et d’y aller à la machette en fonction des injures^Wwarnings
qui apparaîssent.

Y’a pas une ptite liste des depreciations ?

En théorie :

Dans la pratique :slight_smile:
http://www.railtie.net/articles/2006/11/02/deprecations-in-rails-1-2

РJean-Fran̤ois.

Le Jeu 23 novembre 2006 12:34, Jean-François a 飲it :

Pire, non seulement en bloquant sur une stable on se retrouve avec
la phase de développement de la prochaine version majeure,

De toute manière pour une appli en prod, il vaut mieux bloquer une
version de Rails dans vendor/

Certes, mais disons que le RAILS_GEM_VERSION sert quand même justement à
éviter de se retrouver avec un gem tout nouveau à la place d’une stable
bien connue. Là la numérotation rend quasiment inutile (et même négative)
l’utilisation de cette constante.

C’est quand même totalement crétin comme fonctionnement. Ce n’est
pas pour rien que les béta publiques ont généralement le numéro de
version de la cible (ici 1.2.0) et pas de l’origine (ici 1.1.6).

Mais je me trompe peut-être mais on ne doit pas pouvoir mettre
des noms de versions comme rails-1.2.0rc1 dans le système rubygems
c’est pour ça que DHH a utilisé cette ‘ruse’…

Dans ces cas là on voit souvent des “.9”, par exemple numéroter la RC
1.1.99, ou alors faire une branche de dev en 1.3.x et une branche stable
en 1.4.x, ou alors faire un gem “rails-beta” séparé, ou alors à la base
simplement ne pas mettre les RC en mise à jour automatique dans les dépots
gem (mais en téléchargement manuel).

Bref, ce ne sont pas les solutions qui manquent.

Tu devrais soulever la question sur Rails-Core.

Franchement ? pas le temps.
Et puis je serai très inquiet si personne ne remarque les défauts d’un tel
système (donc si personne ne lance le sujet pour moi).

Reste aussi la possibilité que j’ai manqué une marche dans mon
raisonnement et que le problème est évité d’une manière ou d’une autre.


Eric D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs