La question derrière ta remarque c'est: à qui la responsabilité de maintenir 
ces app?

Pour la discussion initiale sur le LTS je suis assez sceptique, parce qu'ils 
ne maintiennent qu'une (grosse) brique de l'écosystème, Rails.

Je pense également qu'au final ça coute plus cher de faire Rails n -> Rails LTS 
-> Rails n+1,
que directement passer de n à n+1

Après le monde de l'entreprise n'est pas celui des bisounours, 
des tonnes de contraintes font que ce n'est pas toujours possible de 
faire (et mieux anticiper) ces migrations.

Le 31 mai 2013 à 19:42, Cyril Mougel <[email protected]> a écrit :

> Dans ma société précédente. J'ai récupéré une app en 2.3.5 ( il y a 20 mois ) 
> elle n'était déjà plus à jour avec les mises à jours de sécurité. A l'époque, 
> on était en 2.3.14.
> 
> Il y a un mois dans ma société actuelle, même version de rails en prod, 
> 2.3.5. J'ai bien sur fait la mise a jours en 2.3.18 depuis. Mais cela me fait 
> dire que beaucoup des applications en 2.3.x ne sont même pas a jour avec les 
> mises a jour de sécurité actuel supporté. Alors même qu'elles sont encore 
> développées.
> 
> Une solution comme ça est bonne si les applications sont déjà à jour.
> 
> Pourquoi 2.3.5 ? Par ce que c'est la dernière version connu comme stable sur 
> 2.3 et avant la sortie de 3.0.
> 
> Le 31 mai 2013 19:11, "Cyril Rohr" <[email protected]> a écrit :
> Pour avoir bossé sur une migration d'une grosse application 
> Rails2.0.2/Ruby1.8.6 (le passage en Rails2.3/1.8.7/Gemfile est déjà un 
> avancement plus que conséquent dans ce cas), je plussoie Thibaut. Je crois 
> qu'on ne se rend pas bien compte de l'état du parc applicatif, même dans les 
> PME. Une LTS permet de donner un peu d'air dans ce cas. 
> 
> Cyril
> --
> http://crohr.me
> 
> On May 31, 2013, at 18:02, Thibaut Barrère <[email protected]> wrote:
> 
>> Le souci n'est pas le temps passé en temps calendaire: c'est le budget et le 
>> personnel à allouer; 3 ou 4 ans pour certaines grosses entreprises c'est 
>> court en pratique (même si ça peut paraître étrange ici :-).
>> 
>> Le problème ne se pose pas trop pour les petites structures très orientées 
>> développement, ou encore mieux, avec 2 applications et demies à migrer.
>> 
>> Pour donner un exemple, sur certains projets avec de grosses boites très 
>> connues, j'ai parfois eu à attendre un an voir deux ans pour qu'un 
>> département dispose d'un budget pour *allouer une personne afin d'étudier 
>> une proposition de migration* (sans parler de faire la migration).
>> 
>> Dans d'autres environnements (je ne cite personne! ^_^), les applications 
>> sont cloisonnées physiquement de partout (applis accessibles uniquement via 
>> un LAN isolé, VPN etc), et pas mises à jour du tout ou très lentement, sur 
>> le principe "si ça marche on n'y touche pas".
>> 
>> Clairement, pour des petites structures agiles, ou bien des structures avec 
>> une unique appli clé, il faut se prendre en main et mettre à jour; par 
>> contre sur des structures beaucoup plus lentes, un LTS (officiel ou fourni 
>> par un tiers) est un argument pour accepter la présence de Rails et de Ruby, 
>> tout simplement.
>> 
>> De la même façon il y a un nombre incalculables de petites/moyennes 
>> entreprises avec des CRM monolithiques maisons fait en Rails, toujours en 
>> Rails 2, et avec aucun développeur employé à bord :-) (j'en ai vu passer 3 
>> dans les deux derniers mois).
>> 
>> Je pense que vous seriez épatés si on avait un sondage fiable en dehors des 
>> sphères "techniques", sur la répartition des versions encore en place. On 
>> est très, très loin du sondage de 2012 encore maintenant.
>> 
>> Enfin une chose est sûre: je pense qu'il est vraiment bon à présent de 
>> coller au plus près des dernières versions, en faisant quand même attention 
>> aux clashs type Rails 3.2.13, et en ayant une suite de tests vraiment bonne.
>> 
>> My 0.02$!
>> 
>> Thibaut
>> --
>> http://www.logeek.fr
>> 
>> 
>> 2013/5/31 Cyril Mougel <[email protected]>
>> Rails 2.3 a 4 ans ...
>> 
>> 
>> 2013/5/31 Cyril Mougel <[email protected]>
>> Pour une comparaison, les LTS Ubuntu desktop sont de 3 ans :)
>> 
>> 
>> 2013/5/31 Cyril Mougel <[email protected]>
>> Rails 3 a déjà 3 ans. Largement le temps en théorie de faire une mise à jour.
>> 
>> 
>> 2013/5/31 Thibaut Barrère <[email protected]>
>> Pour moi le LTS permet d'éviter:
>> - d'avoir des applis complètement coupées (j'ai fait 2 shutdown volontaires 
>> en début d'année sur des applications trop anciennes chez des clients car le 
>> jeu n'en valait pas la chandelle dans ces cas précis)
>> - de laisser des applis en déshérance sur le plan sécurité, en se disant que 
>> ça n'arrive qu'aux autres (très fréquent :/)
>> 
>> Pour par exemple un DSI avec 10 à 20 applications à faire évoluer et avec 
>> seulement 2 développeurs fiables disponibles, ça permet d'éviter ces 
>> situations et de temporiser. Clairement le but n'est pas pour moi de faire 
>> du SLTS (super long term support), juste de temporiser un peu (ce qui peut 
>> prendre un an ou deux selon les contextes plus ou moins agiles), le temps 
>> qu'une DSI puisse reprendre le rythme.
>> 
>> Effectivement il y a le problème de Ruby 1.8.7: cela dit des personnes l'ont 
>> fait et je ne serais pas étonné (si le LTS trouve ses acheteurs) de voir une 
>> bascule vers une compatibilité 1.9.3; par ailleurs les failles Rails ont 
>> offert une plus grande surface d'attaque que Ruby.
>> 
>> En tout cas je suis content qu'une solution existe (la meilleure selon moi, 
>> ce que je fais pour mon SaaS, étant de se mettre au pas et de suivre les 
>> releases), au moins en backup!
>> 
>> Thibaut
>> --
>> http://www.logeek.fr
>> 
>> 
>> 2013/5/31 Olivier El Mekki <[email protected]>
>> Je me demande également comment ça va se passer avec les gems. J'imagine
>> qu'ils ne vont pas garder une copie de toutes les gems de rubygems.org,
>> encore moins dans toutes leurs versions. Ça limite de beaucoup
>> l'intérêt, vu que peu d'application rails n'utilisent aucune gem.
>> 
>> De plus, il ne sera pas possible d'utiliser de nouvelles gems sur le
>> projet, autant dire qu'il sera complètement freezé.
>> 
>> Cela semble être clairement un mauvais choix si le but est de continuer
>> à faire vivre le projet : plus longtemps l'update attendra, plus
>> difficile il sera.
>> 
>> On peut voir cependant quelques cas où ça pourrait être utile, par
>> exemple une application en fin de vie ou en cours de réécriture qui
>> aurait besoin de quelques mois de sursis (ce qui corespond peu cela dit à
>> l'idée de LTS). Je dirais que le LTS rails, c'est l'énergie des
>> développeurs :)
>> 
>> 
>> On 16:21 Fri 31 May     , Cyril Mougel wrote:
>> > Personnellement je ne suis pas convaincu, ne serait-ce que parce que ruby
>> > 1.8.7 ne sera plus maintenu non plus. On va ainsi se retrouver avec un
>> > framework potentiellement maintenu, mais un language qui ne l'est pas.
>> > Enfin, je trouve dommage que des applications ne soit pas mise à jour. Ca
>> > laissera donc cet état de fait :(
>> >
>> >
>> > 2013/5/30 Thibaut Barrère <[email protected]>
>> >
>> > > Moi j'aime assez; je ne vois pas l'aspect community fork dans le sens où
>> > > la version proposée n'est plus proposée en principal?
>> > >
>> > > Ca va me servir car j'ai plus de demande pour des migrations que de mains
>> > > pour les réaliser :-)
>> > >
>> > > Sur l'aspect vieux code: on peut aussi utiliser ça en temporaire, de 
>> > > façon
>> > > à éviter un trou de sécurité, le temps de migrer la totalité des apps.
>> > >
>> > > Vu le rythme des mises à jours en Rails (qui posent problème à certains
>> > > décideurs d'ailleurs, il faut pouvoir suivre), je pense que c'est une 
>> > > offre
>> > > intéressante pour crédibiliser Rails et Ruby dans certaines grosses
>> > > entreprises.
>> > >
>> > > Thibaut
>> > > --
>> > > http://www.logeek.fr
>> > >
>> > >  --
>> > > --
>> > > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" 
>> > > de
>> > > Google Groups.
>> > > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
>> > > [email protected]
>> > > Pour résilier votre abonnement envoyez un e-mail à l'adresse
>> > > [email protected]
>> > > ---
>> > > Vous recevez ce message, car vous êtes abonné au groupe Google
>> > > Groupes Railsfrance.
>> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
>> > > concernant, envoyez un e-mail à l'adresse
>> > > [email protected].
>> > > Pour plus d'options, visitez le site
>> > > https://groups.google.com/groups/opt_out .
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > Cyril Mougel
>> > http://blog.shingara.fr
>> >
>> > --
>> > --
>> > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
>> > Google Groups.
>> > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
>> > [email protected]
>> > Pour résilier votre abonnement envoyez un e-mail à l'adresse 
>> > [email protected]
>> > ---
>> > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
>> > Railsfrance.
>> > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
>> > concernant, envoyez un e-mail à l'adresse 
>> > [email protected].
>> > Pour plus d'options, visitez le site 
>> > https://groups.google.com/groups/opt_out .
>> >
>> >
>> 
>> 
>> --
>> Olivier El Mekki.
>> 
>> --
>> --
>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
>> Google Groups.
>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
>> [email protected]
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
>> [email protected]
>> ---
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
>> Railsfrance.
>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
>> concernant, envoyez un e-mail à l'adresse 
>> [email protected].
>> Pour plus d'options, visitez le site 
>> https://groups.google.com/groups/opt_out .
>> 
>> 
>> 
>> 
>> -- 
>> -- 
>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
>> Google Groups.
>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
>> [email protected]
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
>> [email protected]
>> --- 
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
>> Railsfrance.
>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
>> concernant, envoyez un e-mail à l'adresse 
>> [email protected].
>> Pour plus d'options, visitez le site 
>> https://groups.google.com/groups/opt_out .
>>  
>>  
>> 
>> 
>> 
>> -- 
>> Cyril Mougel
>> http://blog.shingara.fr
>> 
>> 
>> 
>> -- 
>> Cyril Mougel
>> http://blog.shingara.fr
>> 
>> 
>> 
>> -- 
>> Cyril Mougel
>> http://blog.shingara.fr
>> 
>> -- 
>> -- 
>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
>> Google Groups.
>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
>> [email protected]
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
>> [email protected]
>> --- 
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
>> Railsfrance.
>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
>> concernant, envoyez un e-mail à l'adresse 
>> [email protected].
>> Pour plus d'options, visitez le site 
>> https://groups.google.com/groups/opt_out .
>>  
>>  
>> 
>> 
>> -- 
>> -- 
>> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
>> Google Groups.
>> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
>> [email protected]
>> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
>> [email protected]
>> --- 
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
>> Railsfrance.
>> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
>> concernant, envoyez un e-mail à l'adresse 
>> [email protected].
>> Pour plus d'options, visitez le site 
>> https://groups.google.com/groups/opt_out .
>>  
>>  
> 
> -- 
> -- 
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
> [email protected]
> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
> [email protected]
> --- 
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
> Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
> concernant, envoyez un e-mail à l'adresse 
> [email protected].
> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out 
> .
>  
>  
> 
> -- 
> -- 
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
> [email protected]
> Pour résilier votre abonnement envoyez un e-mail à l'adresse 
> [email protected]
> --- 
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
> Railsfrance.
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le 
> concernant, envoyez un e-mail à l'adresse 
> [email protected].
> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out 
> .
>  
>  

Martin CATTY
Gérant, responsable projets.

Standard  :  0805 69 35 35
Ligne dir. : +33 (0)1.84.16.90.21
Portable   : +33 (0)6.07.41.09.69

www.synbioz.com
Libres d'être ensemble.

-- 
-- 
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
[email protected]
--- 
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes 
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, 
envoyez un e-mail à l'adresse [email protected].
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .


Répondre à