On Thu, March 1, 2012 15:03, Rodrigo Rosenfeld Rosas wrote: > > I do respect their opinion. I just think I should state > my opinion too so that their opinion don't become the > only one.
I doubt that will ever be the case. There seems to be some number of people that believe that Rails works well enough for their needs. Beside, here you are only preaching to the choir. Although, I agree that the core team has certainly earned our thanks and deserves to hear it. On Thu, March 1, 2012 16:44, Consu wrote: > > hi, > > until now, I was only a reader, > but this thread bother's me. > > On Mar 1, 9:43 pm, Rodrigo Rosenfeld Rosas > <rr.ro...@gmail.com> wrote: >> From both articles, I've understood that they would >> prefer Rails to be more backward compatible in new >> releases. > > I would prefer it. It's not only a rails issue, also a > plugin / gem issue. > Some time's you got a gem and your app depend's on it, > but it wan't work with a new rails version. What should > I do, in such cases? What will it cost to redesign? > > >> >> I know you want to listen to their critics and that is >> exactly the reason that I felt I should state that I >> prefer the API to be changed to better in major >> releases instead of worrying too much about backward >> compatibility. >> >> Also I do find valuable a small and readable code-base, >> so keeping lots of code just to be backward-compatible >> doesn't feel right to me. > > When I read this I got following question's: > > What's the life time of a rails app? > > Who should use Rails? > > What will it cost in real money, to upgrade a bigger Rails > App? > > How long will there be security-fixes for older Rails > Versions? > > How long will my used plugins be useable? > > In my opinion, it's hard to explain a manager, Yeah, we > have to make a little upgrade from Rails X.Y.Z to X.Y.ZZ, > but it will last 2 weeks, or more because of API changes > and we need to fix some incompatibilities. Such minor > releases have to be drop-in replacements. Personally, I did not find going from 2.3 to 3.0 so hard as to warrant much comment, having previously switched to Bundler in RoR-2.3 using Yehuda's preinitializer hack. And I found the upgrade helper in 3.0 of inestimable value. But it was time consuming and I must confess to a little weariness when some of changes required treading through the source code altering syntax in ways that appeared to me more form than substance. Moving us to 3.1 from 3.0 is only hung up at the moment because of the issue I have encountered with the sqlite3-ruby gem and AR-3.1. That will eventually be solved but it has already taken an inordinate amount of time to resolve and no doubt a considerable amount more will be required. The one thing I do glean from this is that I believe the RoR core team does not consider the desirability of being able to stay current on long term Linux releases as seriously as others who spend money happen to. The "enterprise" is where the money is and "enterprisey" people tend to value stability over new features. I would rather write code for Rails-3.1/3.2 and 4.x when the time comes, but I have to keep existing applications working first. Every hour worked on an existing application simply to accommodate an incompatible change introduced by a point version update to Rails or some other gem it depends upon is an hour lost from other, more profitable, activity. We run systems with OS's CentOS-4, 5 and 6. The 4's are at their end of life, today in fact, and the services that they hosted are almost all moved to 6 based vm systems. But the 5's have an eol five years from now and the cost of moving things off them has to be justified. I can arrange for that to happen using sleight of hand vis a vis switching to virtual machines, but that will take time as well. Deciding to deprecate things provided by mainline core distributions in favour of replacements that may not be supported on, or even available for, a current long term support release I believe is of questionable benefit to Rails in the long term. In our case I was able to use rvm to deal with the requirement for ruby-1.8.7 (CentOS-5 ships only 1.8.6 and we did not run any RoR apps on the 4s) but sqlite is proving to be somewhat more intractable. And given its peripheral use in our application, caused by yet another gem dependency no less, that is almost maddening. Sexy is over once you are married to an app. If you make it hard for organizations to keep the application framework up-to-date without rebuilding their entire platform then they will eventually move to something that makes it less hard. Ultimately it becomes simply a question of where money is spent and who gets to make the decision. >From my own experience I do not believe that this is what RoR is doing, but at the same time I believe that it warrants consideration when making changes. A little PR on the matter might go a long way in RoRs's favour as well. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
