I have bunch of Rails apps running on Rails 1.x. I need to upgrade the gems so the question is, will these old apps still work after I upgrade gems?
Thank you.
The only way to be sure is to test, of course; that said, if you want to be sure the application works while you test, I believe that you can run
rake rails:freeze:gems
to copy the currently installed gems to the vendor folder inside your project. If, after testing, your project can use newer versions, run
rake rails:unfreeze
to return to the system installed versions of the gems.
It depends. If you're talking about upgrading to the latest gems that comprise Rails then if the applications use features that were long ago deprecated and subsequently removed, then they will break.
The only way to know for sure is to try it. Look out for deprecation warnings in the development log. Hopefully you have good test suites in place.
It's just like any other dependency. Look at the version number for each gem:
1.2.3
In this case, 1 is the major version. If this number has changed, then definitely do not upgrade. It will require work to use the new one.
2 is the minor version. You should be safe upgrading if only this number has changed, but be careful. Do a lot of smoke tests.
3 is a bug fix release. You can definitely upgrade if only this has changed. It's unlikely only this one has changed after so long, but if that's the case you're safe.
Unfortunately these are only guidelines, and many open-source projects among others do not follow them very well. So take the advice with a grain of salt.
If you are running with rails 1.x and you upgrade the rails gem, your application will break. Rails 2.x is very different.
Concerning other gems, they might break. Read the releases note, usually authors warn about backward compatibility.
If you don't want to upgrade, you could also freeze the gems.
Related
I have my project on rails3.2.13 and I am having around 80 gems in it,now I need to migrate my project to rails 4,what are the steps I need to follow for successfully upgrading without any gems conflicts and errors.
With so many gems in your codebase I suspect this is a large app and its not going to be a quick upgrade and unless you have been given a large amount of time to do this, your best bet is to break things down and do updates in stages on the old version and then upgrade when you feel the codebase is in a better state.
Before attempting the upgrade I would consider these points and make small changes / releases before any big upgrade project. The less code you have to actually change at the final upgrade stage the less risks you have.
Gems: The more gems you have, the more code that you have worry about and more more code you have to upgrade. Is your app using all these gems and if not can you remove the un-used ones. Are any of the gems really which are pretty basic and can you do the same functionality with just rails / ruby functionality and actually remove some gem altogether. The less gems you have, the less pain you will have when it comes to upgrading.
Tests: Whilst you are working on the code, write tests for any new code that you add or alter and write tests for any core parts of the code.
Latest 3.2 release: Get your coebase running on the latest 3.2 release, this will then include extra warnings of things which may not work that you can sort out sooner.
Deprecated: Are there any deprecated warnings in the logs, if so fix these before attempting any upgrade.
Old code: Is there any code that you know wont work on the later versions, can this be replaced with something that will work on both.
When you feel that the codebase is in a state where it can be upgraded, consider these points.
I would suggest not trying to do to much at the same time: Think about breaking out any ruby upgrade into a separate project from the rails upgrade.
Maybe consider moving up slowly, getting your app onto 4.0 or 4.1 and then re-evaluating things using the points above could prevent less risk to things breaking.
Regardless of how many automated tests you have, get a software tester to run over your app. they will find errors that your automated tests will have missed.
There are plenty of upgrade guides out there that you should take a read of before performing any upgrade.
Good luck.
Till now, I just use the gem name and avoid mentioning the version number, is this a good practice (pros: the gems keeps on getting updated automatically, cons: the app can break)
if it is a good idea to use version number, what are the standard practices to use it ?
EDIT - I just did "bundle show" and it is showing about 30+ gems even though I have only 6 gems listed at Gemfile, I am assuming the rest are core gems which get installed when I create an app, so how to lock them or should I just leave them untouched ?
I thought so too at the beginning.
But then there would be some updates which didn't quite fit to what I coded, or there would be incompatiblie changes which cause feature to stop working.
it happened to me at least twice that I would update a gem at the exact moment the gem was push and I was one of the first few to see it all break due to some bug that wasn't fixed at the time of the push. So you try to debug and it won't work. Since then, I would lock problematic gems and only upgrade them when that's the only thing I'm doing and make sure the functionality remained the same.
It is advisable to use versions which you know that work.
After that you can use gemnasium to keep track on the gems
My suggestion would be YES.
Reason being is that I view external dependencies as potential breaking points as they are out of my control to a certain extent; any change that an external dependency that isn't initiated by me is a potential for a failure.
Since software development is already complicated, I strongly feel that both limiting and controlling external dependency changes works to our advantage.
The less surprise there is the easier it is to maintain code.
HTH
One of the purposes of bundler is to pin your gem dependencies to specific versions. So on the first bundle after you added a gem to Gemfile, the gems will be pinned to specific versions anyhow. You have to specifically do bundle update <gemname> to do an update on a specific gem. Just bundle update (which updates all gems to the most recent compatible versions) defeats the purpose of bundler to a large extent and should be avoided.
that said, I think one should only mention versions in Gemfile if one has a specific reason for it. Example: You want to run rails version 3.2.8 specifically or you have to use ruby-net-ldap 0.0.1 because 0.0.2 breaks some functionality.
I think yes, because in the early days I had so many issue with gems which are updating by themselves, and not backwards compatible.
Normally this happens when you are switching from one major version to another, For me it's Rails 2.x to 3.x.
So the bottom line is it's good to have versions in the Gem file.
It's good to use the exact version numbers. You can probably always just lock it down to a major version, or never specify any version, and be okay, but if you really want that fine grained level of control and to have 100% confidence in your program when being run on other machines, use the exact version numbers.
I've been in situations where the exact version number wasn't specified, and when I or someone else did a bundle install, the project broke because it went to a newer version. This can be especially bad when deploying to production.
Bundler does lock in your gem specifications, but if you're telling it to just use a major release, then it locks that in.
Also if there wasn't a Gemfile.lock, deploying code to production would be a major issue because, as, the dependencies and gem versions could change.
What is the latest stable version of rails? I want to install rails 3.1 but I see there is 3.1.3 now, what is the difference? What ruby version is it most compatible with?
I recommend to always check on GitHub via the "branches" menu what the latest version is on each branch.
You can see the latest version easily by checking the contents of the RAILS_VERSION file
https://github.com/rails/rails
You could also check RubyOnRails.org, but looking at the source code is the most reliable way.
If you already have a Rails App in production, I would highly recommend: don't just blindly take the latest version just because it just came out -- there were many cases in the past where a new version introduced incompatibilities or new bugs which were serious enough to have to wait for a fix before the features in the Rails release were really usable. I know a couple of people who have Production sites and still run 3.0.11 or lower, rather than 3.l.x
Again: check on GitHub under "Issues" which open Issues there are for a release, and/or google "Rails 3.y.z Problems" with the exact version number, so you get a feel of what problems could be introduced by upgrading to a new / the latest version.
On Wikipedia they have a list of historic release dates for the major Rails versions:
https://en.wikipedia.org/wiki/Ruby_on_Rails
The Rails version numbers have been explained reasonably well (Joseph Le Brech's answer), but the Ruby version numbers are slightly confusing and I could see why it's not really obvious what's going on there.
Joseph's explanation of Rails version number scheme is correct for Rails, but Ruby has a slightly different approach
1.9.3 is the most recent version of Ruby. Having said that, it was only released maybe a month ago, so it's possible there are breaking issues with certain gems. (Yes, there were breakages. Ruby in general will introduce breaking things between hotfix releases, and it's true here too)
1.9.2 is a more tried and true version of Ruby, having been out for at least 6 months now.
1.8.7 is the last version in the Ruby 1.8 line. Major language rework happened between 1.8 and 1.9, so some older gems may not have made the transition.
My recommendation: use Ruby 1.9.2 and Rails 3.1.3, unless you have really good excuses not to.
Ruby 1.9.2 is probably the safest bet for a Rails newbie, or green-field projects (projects without a lot of preexisting code). Rails 3.1 is an excellent version of Rails, which solves a lot of problems I had with the framework.
Rails 3.1 was released this fall, so old tutorials won't work, or will give odd errors. Try to look and read what version of Rails the book/tutorial/website/blog entry is talking about, before you dive in.
Latest stable release is always shown on the Ruby on Rails website's home page here http://rubyonrails.org/
To list all rails versions by gem:
gem list -ra rails | grep -G "^rails\ "
It's also helpful for cheeking what is the latest version for 4.x, 3.x and 2.x too.
According to rubygems, it's 3.1.3. Looks like you forgot a ..
major.minor.hotfix hotfixes will never change the behavior of an app unless you previously had a workaround for a bug implemented. Apps can easily be upgraded thru minor revisions, but it's usually not worth it and can be a distraction from getting features out of the way.
The latest release is 3.1.3. This is a minor release which has security and minor improvements.
The main version is 3.1, while minor upgrades are included in 3.1.x releases.
Anyway you should always use the latest one.
usually if you'll pull the latest rails gem, it's the stable one (unless once in history). although you can still use ruby 1.8.x version with the latest rails 3.x, it is more recommended to use 1.9.x.
anyway, everything you might need is in http://guides.rubyonrails.org and some nice people (including myself) are answering all bunch of questions in IRC on irc.freenode.net (#rubyonrails and #railsbridge)
good luck
The latest release is 6.0. it was released on August 16, 2019, making Webpack default, adding mailbox routing. Rails 5.2 is still maintained.
I've spent a fair bit of time with PHP & Python frameworks and recently thought I'd branch out to rails. The framework itself I like, but I seem to spend at least half my development time navigating through odd bugs and/or version incompatibilities between rails/ruby/rake/gems.
I'm happy to battle through it all if it gets less of a hassle, but even after a month it seems like I spend 90% of my time chasing down other people's bugs & only 10% of my time chasing down my own. The only guy I've talked to (who used it extensively until 2008) suggests "For the past 2 years, that's pretty much rails"
Any opinion on this? Does it get better, or is this just par for rails development at the moment?
Running it through Ubuntu 10.04, if it matters.
Rails is in transition right now between 2.3x and 3.0 so you are going to find it quite challenging as much of the most recent documentation and rails plugin readmes are being updated for rails 3. There are several tools that are indispensable right now for negotiating this stuff. First, Rails 3 uses bundler to manage dependencies, it is a much more civil way to manage gems.
gem install bundler
cd my_rails_project
bundle install
RVM (ruby version manager) is awesome and I would recommend installing it. Then you can build gemsets and dependency sets on a per project basis. and you don't need to superuser access to install.
also, if it were me, I'd just go ahead and start in rails 3
gem install rails --pre
if you want to stay with rails 2.3.x use the rake task for installing declared dependencies.
rake gems:install
if the project is a good project, it will be pretty specific about what it needs (declared in the config/environment.rb file), then if it doesn't run, checkout the stack traces to see where its failing.
In my experience this is not par for Rails development.
While using gems read the README file on github project repos and have a look at the issues and wikis....that should give you a fair idea of which gem is compatible with your Rails version. Regarding the framework, it is pretty stable....major bugs or patches or releases are reported on weblog.rubyonrails.org
Things grow incrementally with each release and that is obvious. There are some deprecations which are well documented in the Rails code and are reported when you run the code.
Rails itself is pretty bug free. I've not witnessed a bug in the framework itself now for a while unless I've been duplicating open tickets.
Where the problems you're seeing have crept in have been over a couple of different areas:
We've moved as a community from Ruby 1.8.x to 1.9
over the last year or so, and some
gems have specific Ruby version
requirements you need to check out
before using them. Most of the more
popular gems are fine and tested to
work in multiple environments. Read the docs first.
Rails itself has matured
significantly over the last few
years, and that has meant many
features have been deprecated. Lots
of plugins out there were written
for an older version of the
framework and expect behaviour that
just isn't valid any more. Read the docs first.
Several different Ruby interpreters
are now available (which is great),
but these sometimes can have an
impact when it comes to 3rd-party
code, but that's rare. Basically,
some gems and plugins expect to be
running on a specific interpreter.
None of the really popular ones are
like this, but you need to be aware
some gem builders are idiots. Read the docs first.
You might notice there is a common theme to the end of each point: read the docs first. :-)
I would say your experience is not at all typical of most Rails developer's workflows, although we've all had a day of struggling from time to time.
You will learn quickly which gems to trust, which ones you'll need but may struggle with from time to time (mysql - building that kills me on OS X, every time), and which ones you should avoid.
Overall though, the development cycle is more fluid (and you'll develop more rapidly) with Rails once you've got your bearings and are adopting good practice. There's a reason why we all like TDD and BDD though - if nothing else it helps us get through a gem update knowing stuff still works when a developer we don't know has done something moronic. :-)
I recently started working on a small personal project in Ruby on Rails, and have run into a few things that I couldn't find definitive answers for. If anyone here is knowledgeable enough to help, that would be greatly appreciated. All of my questions are below:
What benefit is there to using the Rails Gem instead of having it in vendor/rails?
Is there any benefit to using Rails 2.3.2? Some of the plugins I hoped to use don't seem to be compatible with 2.3.2 (ActiveScaffold)? Does it offer a great improvement over 2.2?
What is the benefit of using Ruby 1.9? Many plugins aren't yet compatible. Does it offer a great improvement over older versions?
Thanks for any help you guys might be able to offer.
vendor/rails probably makes your project more portable. Deployments that run the rake gems:install can act kind of wonky, especially if you upgrade a "Framework Gem" (you have to do these manually).
The downside to vendor/rails is that it makes your deployment slightly bigger (more files that have to be pushed) but if you use git and something like Capistrano, this only bites you on the initial deploy... but its not that bad.
I don't think there are any huge benefits; it just depends on if you need features from 2.3.2. Obviously you want to try to run the latest version to make upgrades less painful. I've found that you always need to be upgrading the framework underneath Rails if you want to have any change of upgrading in the future.
Performance. As you pointed out though, a lot of plugins are broken. This is sort of a chicken-and-egg problem but overtime this should fix itself. We're not running 1.9 yet in any of our production apps because its too unstable with the rest of the stack.
I'll address the gem question.
I've used vendored gems in the past but I have pretty much moved away from it except in the rare case where I need to fork a gem to customize it for some purpose in which case I would vendor the gem.
The main reason not to vendor from my perspective is that you can't cleanly vendor any gems with C modules since they require compilation.
A really good option is to use a gem management tool such as geminstaller, it lets you configure the gems and specific versions of gems that your project works against so that you have a consistent set of gems on your deployment.
What benefit is there to using the
Rails Gem instead of having it in
vendor/rails?
The biggest benefit is that you do not carry around the full rails source code with your project, the other benefit is that moving to a newer version of rails is going to involve less effort.
Keep in mind that the gem command will allow you to install a specific version of a gem.
Is there any benefit to using Rails 2.3.2? Some of the plugins I
hoped to use don't seem to be
compatible with 2.3.2
(ActiveScaffold)? Does it offer a
great improvement over 2.2?
A lot has changed from rails 2.2 to 2.3.2, there are also a bunch of security, performance and bug fixes. ActiveScaffold is compatible with rails 2.3.2, as are most of the plugins out there. If you are starting a new project I would recommend using the latest and greatest.
What is the benefit of using Ruby 1.9? Many plugins aren't yet compatible. Does it offer a great
improvement over older versions?
Ruby 1.9 is much faster than Ruby 1.8.x, however adoption of 1.9 is not that high. Rails 2.3.2 works just fine on Ruby 1.9, however there are some plugins and gems that do not. Make sure you read this stackoverflow question on the topic.