I'm using RVM to install Ruby on production server. Listing the known rubies gives me
[ruby-]2.2.0
[ruby-]2.2-head
Is it safe to use 2.2-head in production mode or better rely on 2.2.0?
Better use 2.2.0 in production.
As it is stable.
Every month or two a stable release of RVM is created, it includes minor version increase. Between releases only bugfixes and ruby version updates are added to it with teeny version update. Normal development and major changes continue on master branch to install it use head version. It's important to use head version before reporting errors as those could be already fixed.
Related
I am working on a server migration and upgrade, and I don't code in Ruby at all.
Is there an easy way for me to scan / review the gemfile / installed dependencies to check that latest updated / unpatched dependencies?
The code references to a hundred at least dependencies and I am not sure which are no longer the latest stable version.
You can try bundle with the outdated command and using the --strict parameter to make sure it lists only compatible gems:
bundle outdated --strict
But like I said in my comment above, you usually want to know what you are doing if you plan to upgrade any gem. Any changes to the API or functionality of a gem may break part of or the entire codebase. Make sure you have working backups.
This is what I am talking about.
My attempt is to repush the exact same version, 0.1.12.
My previous push is invalid, it broken gem what I push.
I highly want to publish this version, like I already implement the sem-versioning.
the pushing process yield:
Repushing of gem versions is not allowed. Please use a new version and retry
So is it possible? if not what is the main use of yanking a submitted gem?
Nope, you can not re-submit the same version number, this is made on purpose for security reasons, avoiding maintainers to upload the same version without getting noticed by the developers. So you will need to release a new version of your gem
Why should one care about specifying gem version at all if bundler detects Ruby version and manages to get the latest release to match that version. If I'm not a fond of newer version personally, I would disable incrementing with ~> 1.4.4 and in other cases I'd let bundler manage stuff with putting gem name into Gemfile without any argument
The approach you are suggesting - start with the latest version and pin if problems are experienced - works fine for projects that are 1) actively maintained and 2) tolerant of breakage.
Now imagine you have to deliver this project to a customer who then will run it for a year or longer and you won't be there to support it. In this case simply getting the latest release of all dependencies is not necessarily the best strategy. Maybe you would proactively specify major versions of all of your important dependencies instead. Potentially even lock to minor versions which does give more stability at the cost of missing security updates/bug fixes.
Isn't the Gemfile.lock a hack used to perpetuate bad practices in dependency version control?
I.e. Shouldn't developers set the dependency version ranges strictly in the Gemfile?
For example if my Gemfile says that I depend on gem A version 1.0.1 or versions [1.0-2.0), why would I need the .lock?
No, Gemfile.lock makes a lot of sense and is crucial to the concept of automatically picking gem versions. As a developer, you do not need to bother about exact version numbers. You can say "give me whatever version of gem X fits all other versions of all other gems" (by just saying gem 'xyz' without any further information). Or you can tell it to stay within the bugfixing line of an older version of a gem (gem 'xyz', '~> 2.3.0') or whatever.
By adding the exact version in Gemfile.lock you then make sure that the versions stay consistent for all developers (and environments). You make the act of upgrading to a newer version of a gem a conscious (and well-documented) choice instead of a random part of your build/deploy process.
why would I need the .lock?
to install exactly the same versions as all the other guys in the team. Or install in production the same versions that you use in development.
It might happen that a new version of some gem is released while you were collecting sign-offs for your release. You better be sure you install/load exactly the versions that you developed/tested with.
There are quite a few versions of Ruby 1.9 floating around. There are a few Ruby 1.9 builds for the different operating systems at the official Ruby language site here:
http://www.ruby-lang.org/en/downloads/
There are also other 1.9 versions at Ruby Forge:
http://rubyforge.org/frs/?group_id=167&release_id=38052
What are the differences between them? And which one should one be learning?
I ask this because I started taking a Ruby course at http://rubylearning.com/ and they recommend downloading ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32] but do not really state why. Also I see other people using different builds of 1.9 so I am curious about the differences.
Thanks,
caeious
There are three main versions of Ruby 1.9 on ruby-lang.org:
Stable: this is the one that most people should be using, as it's the latest stable release
Stable snapshot: this is the latest version of the development branch in SVN that has been marked as 'stable'. It's an unreleased version that's still being worked on, and should only be interesting to those wanting to test out the upcoming Ruby version.
Daily snapshot: this is a snapshot of the development branch in SVN, taken every day. Should be pretty unstable, and only recommended to those wanting to develop Ruby itself.
For your Ruby course I'd definitely use the latest Stable release, so the recommendation you got seems about right.