Last week I had my first meeting with Eric and Ryan to help ease tensions around RubyGems. That meeting was productive, and much of the feedback we received afterwards was helpful as well. However, at that time we didn't get a chance to discuss the one issue that everyone seems to care about, Rubygems release management policies.
Tonight I followed up with Eric and Ryan, and shortly after we started talking, we pulled Evan Phoenix into the conversation. Since Evan is both a RubyGems and Bundler maintainer, it was great to get him involved in this process. The following list outlines the changes that should happen as a result of this meeting:
- Starting with Ruby 1.9.3, any independently released versions of RubyGems will maintain backwards compatibility with the version of RubyGems that ships with the latest stable version of Ruby. The feature freeze for Ruby 1.9.3 is happening very soon, so be sure to note that this isn't a far future goal.
- The current plan is to ship RubyGems 1.8 with Ruby 1.9.3. RubyGems 1.8 works with Bundler as of right now, and the very next maintenance release of Rails 2.3 will ensure RubyGems 1.8 support as well. Many have reported that RubyGems 1.8.4's removal of the default_executable deprecation has completely silenced the warnings they were seeing. One more common deprecation (has_rdoc) will be removed from RubyGems 1.8 before it is merged. Some other deprecations (such as those surrounding SourceIndex), will remain in place to ensure that these APIs can change in the future, but these should not have a major effect on ordinary users.
- The current frequency of point releases and rapid changes in RubyGems releases has frustrated users. To compensate for this, stable releases will now trail one month long periods of beta and release-candidate testing, so that issues can be found and fixed before they hit the general userbase. This means that there will be a month of cooldown on any major changes to RubyGems before they reach ordinary users. This should hopefully cut down on the number of point releases.
- Evan Phoenix will (at least for now) be handling release management for the stable branch of RubyGems. Additionally, he will be more involved in handling support requests, providing an extra person to talk to on the team other than Eric and Ryan. Because Evan is also a Bundler maintainer, he can help handle issues that lie in the intersection of RubyGems and Bundler problems.
- The versioning scheme is still going to follow a sort of Ruby-esque versioning policy, which is a bit more fluid than semantic versioning. But with the commitment to make sure that independently released versions of RubyGems serve as a backwards compatible superset of whatever ships with core Ruby, this should provide a compromise between stable API for extensions to target as well as new improvements for those who want to track the latest changes. This combined with the month long grace period should help reduce the amount of compatibility and interoperability problems people have been having.
In addition to the above decisions, a few points were brought to light which I found particularly interesting. Despite the deprecation of SourceIndex, Evan says that Bundler is working fine using Gem::Specification on top of RubyGems 1.8. While there is support in Bundler for older versions of RubyGems, the latest release works against the new RubyGems APIs just fine.
Additionally, Evan asked me to point out that any perceived issues with integration between Bundler and RubyGems may be outdated or incorrect, unless the issues have been confirmed by Evan himself or by it's other primary maintainer, Andre Arko. There were many issues in the past, many have been corrected, and having Evan on both teams has really helped things. In fact, Bundler has for months had continuous integration set up that gives them real time notification whenever there might be issues at the interaction points between RubyGems and Bundler.
What happens next?
At this point in time, it's important to be looking forward, rather than backwards. No matter what your issue with RubyGems was in the past, some serious changes have been made to help encourage us all to move forward. I've checked in with Eric and Ryan about the action items from last week and all of them are still on the radar and being acted upon. I'll be sure to follow up on this week's commitments as well, to make sure that these plans are being put into action.
Right now, the only concrete thing I still have on my TODO list is to investigate the plugin system and get some clarifying documentation out that makes it clear what it is, what it's there for, and what you can and cannot expect to be able to do with it. What else should I bringing to the table for consideration?