Now is a fantastic time to follow Ruby’s development. With the increased attention Ruby has received in the past few years, there’s a growing need for good talent to help enhance Ruby and document its parts. So, where do you start?
The topics related to Ruby development covered here are:
- Using Subversion to Track Ruby Development
- How to Use Git With the Main Ruby Repository
- Improving Ruby, Patch by Patch
- Rules for Core Developers
Using Subversion to Track Ruby Development
Getting the latest Ruby source code is a matter of an anonymous checkout from the Subversion repository. From your command line:
ruby directory will now contain the latest source code
for the development version of Ruby (ruby-trunk).
Currently patches applied to the trunk are backported to the stable
and 2.2 branches (see below).
If you’d like to follow patching of Ruby 2.4,
you should use the
ruby_2_4 branch when checking out:
Similarly for Ruby 2.3:
This will check out the respective development tree into a
Developers working on the maintenance branches are expected to migrate
their changes to Ruby’s trunk, so often the branches are very similar,
with the exception of improvements made by Matz and Nobu to the language
If you prefer, you may browse Ruby’s Subversion repository via the web.
How to Use Git With the Main Ruby Repository
Improving Ruby, Patch by Patch
The core team maintains an issue tracker for submitting patches and bug reports to Matz and the gang. These reports also get submitted to the Ruby-Core mailing list for discussion, so you can be sure your request won’t go unnoticed. You can also send your patches straight to the mailing list. Either way, you are encouraged to take part in the discussion that ensues.
Please look over the Patch Writer’s Guide for some tips, straight from Matz, on how to get your patches considered.
To summarize, the steps for building a patch are:
Check out a copy of the Ruby source code from Subversion. Usually patches for bugfixes or new features should be submitted for the trunk of Ruby’s source. Even if you wish to add a feature to Ruby 2.3, it has to be proven in the trunk first.
$ svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby
If you are fixing a bug that is specific to only one maintenance branch, check out a copy of the respective branch, e.g.
$ svn co http://svn.ruby-lang.org/repos/ruby/branches/ruby_2_3
Add your improvements to the code.
Create a patch.
$ svn diff > ruby-changes.patch
If there are no issues raised about the patch, committers will be given the approval to apply it.
Discussion of Ruby’s development converges on the Ruby-Core mailing list. So, if you are curious about whether your patch is worthwhile or you want to spark a discussion about Ruby’s future, don’t hesitate to come aboard. Be warned that off-topic discussions are not tolerated on this list, the noise level should be very low, topics should be pointed, well-conceived and well-written. Since we’re addressing Ruby’s creator, let’s have some reverence.
Keep in mind that Ruby’s core developers live in Japan and, while many speak very good English, there is a significant timezone difference. They also have an entire body of Japanese development lists happening alongside the English counterparts. Be patient, if your claim isn’t resolved, be persistent—give it another shot a few days later.
Rules for Core Developers
Generally, the developers of Ruby should be familiar with the source code and the style of development used by the team. To be clear, the following guidelines should be honored when checking into Subversion:
- All check-ins should be described in the
ChangeLog, following the GNU conventions. (Many Ruby core developers use Emacs
add-logmode, which can be accessed with the command
C-x 4 a.)
- Check-in dates should be given in Japan Standard Time (UTC+9).
- The bulleted points from your ChangeLog should also be placed in the Subversion commit message. This message will be automatically mailed to the Ruby-CVS list after you commit.
- Function prototypes are used throughout Ruby’s source code and its packaged extensions.
- Please, do not use C++-style comments (
//), Ruby’s maintainers instead prefer the standard C multi-line comment (
/* .. */).
See also the information in Ruby’s issue tracker.