Rubygems Online Tutorials

Development on RubyGems started in November 2003 and was released to the public on March 14, 2004, or Pi Day 2004.

It was created by Chad Fowler, Jim Weirich, David Alan Black, Paul Brannan and Richard Kilmer during RubyConf 2004.

In 2010, the default public repository for gems moved from gems.rubyforge.org to rubygems.org, which is still in use. Also, RubyGems development was moved to GitHub in 2010. Though RubyGems has existed since Ruby 1.8, it was not a part of the standard Ruby distribution until Ruby 1.9.

There were 38 releases from 2004 to 2010.^[5]

Previously, compatibility with RubyGems and Ruby varied. Many versions of RubyGems are almost fully incompatible with many versions of Ruby and some versions had key features unusable. For example, Ruby 1.9 came with RubyGems 1.3.7 in its standard distribution, but RubyGems 1.4.x was not compatible with Ruby 1.9. This meant that updating RubyGems on Ruby 1.9 was not possible until RubyGems 1.5.0 was released in 2011, two years after the first stable release of Ruby 1.9.^[6] These compatibility issues led to a rapid development of RubyGems, switching to a 4–6 week release schedule, and more version releases.^[5]

There were 117 releases from 2011 to 2016. 45 versions were released in 2013, which is the highest number of releases in a year for RubyGems.^[5]

Every gem contains a name, version and platform. Gems work only on ruby designed for a particular platform based on CPU architecture and operating-system type and version.^[7]

Each gem consists of:

The code organization follows the following structure for a gem called gem_name:

gem_name/
├── bin/
│   └── gem_name
├── lib/
│   └── gem_name.rb
├── test/
│   └── test_gem_name.rb
├── README
├── Rakefile
└── gem_name.gemspec

• The lib directory contains the code for the gem.
• The test (or spec) directory is used for testing.
• Rakefile is used by Rake to automate tests and to generate code.
• README includes the documentation, RDOC, for most gems.
• Gem specification (gemspec) contains information about the author of the gem, the time of creation and the purpose the gem serves.

Since gems run their own code in an application it may lead to various security issues due to installation of malicious gems. The creator of a malicious gem may be able to compromise the user's system or server.^[8]

A number of methods have been developed to counter the security threat:

• Cryptographic signing of gems since RubyGems version 0.8.11. The gem cert and gem install commands are used for this purpose.
• New signing models such as X509 and OpenPGP have been proposed and are actively being discussed among Ruby experts.