As Rails does change quite a bit fairly quickly could somebody please share their experiences maintaing an existing application as Rails develops. How does a hosting service like Heroku handle this? Do hosts support legacy versions of rails or would one be at the mercy of the host to upgrade an app?
Edit:
With a framework such as Asp.net which is not updated that frequently, it would seem to me that fewer apps would be broken due less quickly. Is a developer always chasing after the next version of rails?
With Gems and now Bundler, this isn't really an issue. To keep your application up to date, all you have to do is tell it which version of Rails to bundle with your app in the Gemfile: gem 'rails', '3.1'. This works for any version, past or current. The only thing you have to worry about is the libraries like Ruby, but any version of Rails will work on most versions of Ruby. Plus, most hosts will even allow users on shared servers to compile your own Ruby if you want.
Hosts definitely support 'legacy' versions up to a point. I think even GitHub is on Rails 2.2, though they might be self-hosted.
Hosting tends not to be that big of a deal with respect to new rails versions, however. It's the community. Gems, plugins, and systems come in and out of fashion at blinding speed in the Rails community and you can quickly find yourself committed to a pile of unmaintained contributed code. Most new gems now ONLY support Rails 3, so if you have a 2.x.x app and want to use those things, you're SOL unless you backport it yourself.
So yes, you are chasing Rails versions over the long period. There's 2 ways to solve it: either walk away from every app you write after it's finished, like a consultant, or keep your app small. If you want to build a large, feature-filled platform, you can't build it as one app. You'll get stuck on a Rails version forever and have to rewrite it eventually anyway. Just set a threshold and say when this app is over 10,000 lines, it's time to break it up into services so it doesn't get fossilized.
Related
whenever some major rails version bump happens, sometimes its real pain to upgrade existing apps for rails (4.x, 5.x etc), given there are plenty of gems which might depend on older versions of rails (ActiveRecord, ActionController, ActiveModel, etc.). And those dependent gems sometimes takes too much time to be upgrade (either not maintained, less active or unavailability of core maintainer team, even for accepting Pull Requests). What is the solution which people around follows for the same?
One workflow which people suggest is fork all the dependent gems and then change whatever you like and keep updating them from their respective master/main branches. I would love to hear what people follow in their workflow.
I would argue that you should remove/replace gems that do not have a compatible version available shortly after a major Rails update.
Beta versions of Rails 5 were available almost 6 months before Rails 5 was released. If a gem doesn't update within that time it will probably not be updated later on or it will slow do down on every other Rails update as well.
I see several options when you run into that situation:
Revisit the reason why you are using that gem. Sometimes you use a gem for a few simple methods. Rewrite those methods in your application (or your own gem) and remove this dependency.
Are there other projects available that solve the same problem? Sometimes these projects even have a better structure or other benefits. You might consider switching to that gems. Hopefully, you encapsulated the old gem and didn't customize that gem too much, because that makes it harder to replace it.
You might consider forking that gem and fixing the problem yourself (bonus points for sending a pull request to the original gem). That is an okay solution in the short-term. But you will very like have a similar issue with this gem with the next Ruby version. Furthermore, when you work with a forked version of a gem, you are on your own. Do you really want to maintain that private gem version for the following years?
With every gem that you add to your stack, there is a cost and a risk coming into your application. The cost of watching that gem, how does it change, are there security fixes? And the risk that the gem will be abandoned at some time.
There might be some things you can do upfront to decrease the pain when you run into situations like this:
Avoid adding gems to your application, when you only need a few simple helper methods from that gem.
Encapsulate that gem with your own wrapper. And have good test coverage for your wrappers interface. That makes it much easier to change the underlying gem.
Always be prepared to remove/replace gems as soon as you face a problem with them. Waiting for an external gem maintainer is probably not a good strategy when you have problems in your application to solve.
We are currently running rails 2.1.
My main motivation for the upgrade is the fear that gems/plugins will get rarer/unavailable/unsupported day by day for our version (,and the excitement of the latest technology).
I understand there are many-many improvements that come with rails3, but probably what my manager would want to listen is the advantages that he'd get, in terms of the business.
Ours is a Saas application, load on the app is not very high, but the demand for reliability is more.
Edit :
Looks like my inclination towards the upgrade needs rethinking, so answers to "should I upgrade" are welcome.
my original question also needs answers - how to describe the business advantages of an upgrade from rails2.1 -> rails3.
The app is under active development/enhancements.
The longer you go without upgrading, the harder it will be when the time comes. Sooner or later, any actively maintained project is going to have to move up to the more recent versions, and the more versions you have to skip along the way, the harder and more risky it will be. If you upgrade regularly, it becomes a fairly simple maintenance task.
I'm afraid that going from 2.1 -> 3.0 is going to be a fairly rough one unless your app is pretty simple. You might try going from 2.1 -> 2.3.9 as a first step. However, doing it now, instead of when it's 2.1 -> 3.1 will save you heartache. Right now, everyone is focused on helping people upgrade. A year from now, there will be fewer fresh resources available and fewer people going out of their way to help people upgrade.
If your application is under development and is likely to have more and more features over the months to come then you should migrate to the newer and actively supported version.
If your application only needs bug fixes occasionally then you should stick to the current version.
Upgrade!
I'd say that you should definitely upgrade, for the reasons you stated, but don't rush it. If you have a well defined test suite everything should be ok.
Most of core Rails 2.x code works with Rails 3, you can just read the deprecation warnings and fix things one by one. You can also use the official Rails Upgrade plugin to automate the bulk of the editing.
As for the gems and plugins you use, you can check their compatibility at railsplugins.org and decide if it's worth the trouble if any.
And the elevator pitch for the boss: You said the app is under development, so upgrading later when you absolutely have to means that you have to first deal with all the issues arising under 2.x and then deal with the upgrade issues plus 3.0 issues of a much bigger app. Upgrading now saves time by saving you the trouble of having to deal with 2.x issues. And you also avoid some of the upgrade issues since your app is probably much leaner now than the heavyweight it will be when you decide to upgrade later.
Since reliability is high on priority, you should probably not upgrade unless it's absolutely required. Some unforeseen issue is bound to come up.
To address the excitement of the latest technology, you can always try out new plugins and Rails 3 offline.
Businesses should not be sandboxes of developers. Nor should development be Resume Driven.
But that's just my opinion. :)
There are several reasons to upgrade, all of which are under the assumption that the app is and will continue to be under active development.
Integration with 3rd party software- for example, rails 1 did not have ActiveSupport. An app remaining on rails1 all through say rails 2 might want to integrate with a 3rd party API that primarily supports restful json. At that point, the sensibile path is to upgrade, but since you delayed it so long your risk of having lots of issues in the upgrade will be significantly greater than if you upgraded early.
Using plugins that will help with new features - if you want to add a new feature and someone has scratched your itch already, then if you are stuck on an older version of rails you will have to write that code yourself. The more code you have to write yourself, the greater the likelyhood of bugs and the more maintaince the code will likely require, depending on the function.
Fixing bugs in older verisons of the plugins/gems - if you encounter a bug in rails, or a plugin, or a gem, or some sort of other integration issue, it might be fixed in a later version, but what that depends on a newer version of rails. This will make your path to fixing said bug or implementing said enhancement greater the longer you wait to upgrade.
I heard Rails 3 is almost ready to be released from beta, meaning its a stable version. But of course the real date still unknown.
So I'm looking for advice from a good RoR developer. Do you think I should learn and use Rails 3 RC version or use Rails 2.3.8? If I use the RC version now will it be hard to upgrade to the stable Rails 3 version?
Is there a decent RoR developer out there than can offer some guidance?
Thanks.
I don't know what a rock developer (!) is, but I'd recommend going with Rails 3 rather than Rails 2.x. Rails 3 represents the future direction of Ruby on Rails, so it's worth getting up to speed with it as soon as you can. To be frank, Rails 2.x is now an evolutionary dead-end. There shouldn't be any significant changes between the Rails 3 Release Candidate and the final version.
The barriers to adopting Rails 3 you might encounter are:
its availability on your production stack
plugin/gem compatibility
For the first issue, I know that the popular Heroku for example are tracking the Rails 3 beta releases pretty closely. Regarding the second issue, not all plugins or gems are compatible at the moment, but a lot of the most popular ones are. If there are specific plugins or gems that you need to use then check here.
If you need to get a project off the ground now, then by all means go with Rails 2.3.8. It's the safe choice.
There are some significant changes in Rails 3. Some tools will be available to help you upgrade. But no automated tool will ever completely convert your 2.3.8 application to Rails 3. It's hard to tell how much effort is involved, that really depends on your application.
That said, if you are new, learning, and not expecting to release anything for several months, Rails 3 is the right choice. By the time your grok Rails and have something in production, Rails 3 will likely have stabilized, and nobody will be looking back.
Use rails 3!! The RC is still in the pipeline, but it's more or less good to go and you won't need to make any code changes when the final release is made
Here are some reasonable resources to get you started with it
http://railscasts.com
http://www.railsdispatch.com/
http://www.teachmetocode.com/
http://rubyonrails.org/screencasts/rails3/
I want to develop an application in Ruby on Rails. I have used rails(vigorously) a couple of years ago. since then i haven't given it a try, i have been concentrating on core ruby. At that time, Rails(1.2.x) used to be a bit slow! so my problem is whether i should go for the earlier slower version or should i try newer versions... is it fast and STABLE? And does it have proper support for all the gems that were made for earlier versions?
Thanks
Compared to two years ago, you should be impressed with where Rails is at. Here are some things to take note of.
mongrel is still fine as a server, but many (most?) people are using Phusion Passenger. I'm running a few apps in production mode with Passenger, and it's great. It plugs into Apache with a very small and simple set of directives. You won't have to set up balancers or rewriters like you used to.
Phusion also offers RubyEE, which is their own, more efficient version of Ruby. The installer works in such a way that if you decide you don't like, it can be removed by simply deleting its directory. It's all self-contained.
rmagick is still just as awful to install as it ever was, but now there is Paperclip as an alternative.
You'll love how fast 2.3 loads the console.
named_scopes are a huge step forward. Be sure to read up on them.
There are dozens of other reasons to upgrade, most of which can be found on this site. Unless you have an axe to grind with Rails, I doubt that you'll be disappointed with it.
Now, when you ask about stability, the answer is "sure, it's stable." However, you gave no information regarding what types of user loads you're trying to support. More detailed questions could lead to more detailed answers.
Edit
Answering your comment.
10 Cool Things in Rails 2.3 by Luke Francl. This is a nice summary of the latest highlights.
No problems with Rails 2.3 yet! No Problems with gems as well! Give it a try, it rocks! ;)
2.3.4 is stable enough if you are running Ruby 1.8.6/7, not so much if you are running Ruby 1.9.1 (even though it should technically support it properly).
If you are going to run Ruby 1.9.1, good on you, the speed improvements are really good, however you will have to be aware that some things wont work as intended and will need some patching of either core Ruby or Rails.
Saying that I would still avoid REE. Anything that has malloc'd for me in development I wouldn't trust in production.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
Now that the Rails 3 beta is here, let's take a little straw poll.
Please tell us briefly what your application does and when you will upgrade it to Rails 3. Or, if you're not planning on upgrading any time soon, tell us what's stopping you.
Honestly? When developers wake up and start work on Rails 3/Ruby 1.9 in their gems and plugins. They know it's been coming for several months now, and most haven't even bothered to upgrade. One in particular that I'd like to point out is authlogic, one of the most used authentication plugins out there. It still doesn't work for Rails 3.
Whoops!
I'm not planning to. I'm sure I'm in a very small minority, but my big application is still running 1.2.6. Each time I consider making the effort to upgrade it seems Rails changes again.
It does what I want it to do, makes good money, and despite feeling more and more left out in the cold I just don't have a sufficiently compelling reason to update it.
All my Rails apps are currently running under Rails 2.3.5 and every app has a LOC of 80% or greater. This has always been a key requirement for every product I create for myself or I manage at work.
Usually, upgrading to a minor/bugfix release is just a matter of a few minutes.
Change GEM version, upgrade requirements, run tests, fix issues and commit.
Rails 3.0 is a major rewrite and the biggest problem is represented by plugin compatibility.
Plugins are not under my direct control. This is the same reason why I had hard time trying to upgrade to Ruby 1.9.1.
However, I'm already playing with Rails 3. I want to learn the most important changes of Rails 3 as soon as possible in order to start moving the existing apps to the right directions. Moreover, as a plugin author, it's important to me to start working with Rails 3 in order to make my plugins compatible.
Yesterday I start with my most simple app. Well, at least this is what I was used to think about it. Anyway, it is the app with the lower number of external dependencies (less than 3 Gems) and it took about 1 hour to upgrade and 3 hour to figure out why Rails was failing to load my routes. It turned out, the Rails Metal component was fighting with the new Rails 3 stack.
There are some minor issues I have to figure out, but I can say I successfully migrated my first app to Rails 3.
I'm planning to migrate all my Rails apps to Rails 3 as soon as possible, once Rails 3 stable will be available. Or at least, as soon as I can figure out whether the dependencies actually work with Rails 3. Fortunately, a project has been started at http://railsplugins.org/ with the intent of listing all compatible/incompatible Rails plugins.
My remote environment is already compatible with Rails 3, I'm using Passenger with Ruby Enterprise Edition (1.8.7). The only blocking issue are plugins.
I guess it would take at least one month before having the major part of my Rails app ready for Rails 3 thought I won't probably start the upgrade until Rails 3 stable is out or I really need the new version for some blocking feature (ex. subdomain-based routing).
I'm not going to upgrade any apps to rails 3.
However, I just decided that all new projects will be rails3 going forward. The lack of plugin support isn't a big issue as I see it as an opportunity to decouple my apps from plugins so that I can swap them in and out as I please later.
I also suspect that the big plugins will upgrade very quickly as they won't want to be left in the dust.
Keep track of plugin status here.
I've been keeping my apps on the edge of 2.3, but since there's a lot of fundamental changes to Rails in 3, I'll probably install the beta, work on converting them over and hope to be ready by the time it's released as stable.
I'm also glad there's a lot of lead time before RailsConf so I can really get familiar with the new features of Rails 3 and won't feel lost/overwhelmed there.
I don't think I'll upgrade any of my applications. It would be a large amount of work compared to what I'd gain from it. Also in some cases the plugins/gems I used in my app are not compatible with Rails 3 so upgrading would be impossible or would require to fork the gems... too time consuming.
If I had to update, I'd probably wait a bit more for all the gems/plugins to be updated to Rails 3. Of course any new application I'll develop will be done using Rails 3.
I'll answer my own question.
I'm not sure how many betas there are going to be for Rails 3, but I'm going to hold off converting my blog application until the next beta or the final release. I think it's going to be quite a time-consuming process because I have a lot of view helpers that build markup, a lot of named scopes and some quite complicated routing.
I want to add page caching first before tackling Rails 3!
After trying out the beta and it not wanting to work with any commands, I have decided to wait until a new beta.
The ticket has already been opened for the issue.
After realising that I probably spend more time in Zend Framework and Doctrine getting code to work (fixing framework bugs, annoying language workarounds, and just plain pain), than actually coding features I decided that it's finally time to give RoR a go. Especially as RoR3 is now out with a bunch of documentation.
5 hours through and it's looking really promising. 1 hour of it was debugging though, some documentation on a plugin was not up to speed, but alas I'm there.
It's interesting, and does seem to be in a better direction. More time to code on features, and less time coding to debug.
So the app I'm converting is my premium CMS that is deployed in over 20 websites now, and powers my own balupton.com - so will be interesting, as the CMS is already a complete featured cms.