Hacker News new | past | comments | ask | show | jobs | submit login
Establishing release management policies for RubyGems (majesticseacreature.com)
23 points by sandal on May 31, 2011 | hide | past | favorite | 6 comments



Looking good. Reading this though, I couldn't help thinking that Bundler and RubyGems should possibly be the same thing. They are both pretty much essential to running/developing any non trivial Ruby application. Why not make them the same so we don't have compatibility problems? This would remove a lot of code from Bundler that is used for supporting a bunch of old versions of RubyGems. It would also pretty much dissolve compatibility problems between the two, since there would be test coverage to make sure everything worked for that version.


There are certain parts of Bundler that can (and perhaps should) be merged into RubyGems. Now is not the time to work on that, but after Ruby 1.9.3 is out, consider raising this question with Evan, as there is some potential there.


Not everyone wants to use bundler.


I'm not advocating requiring bundler (that would be stupid). I'm just saying that they seem to go hand in hand, bundler could be a "feature" to RubyGems, kind of like how Capybara "absorbed" Steak, since it was a natural extension/feature.


I'd like to hear more about what is being done on the packaging front, specifically Rubygems v Debian.

Last I heard, the Debian folks weren't too happy with RubyGems because people who install RubyGems can upgrade gem dependencies without updating dpkg resulting in an inconsistent state. IIRC there was effort underway to bring RubyGems and all of it's gems into the dpkg repository.


The Debian situation has always seemed a bit unreasonable to me because RubyGems is designed to be a tool for Rubyists, not sysadmins. The overhead of doing operating system level integration to respect various package systems and the way they work would be way too much for the RubyGems team.

However, if changes need to be made to allow third party packagers (such as Debian) to use RubyGems in the way they want, those issues should be revisited. It's not reasonable to expect RubyGems to change its core focus or support lots of Debian specific functionality, but it is reasonable to think that if all that is needed is some extension points or something like that, the issues should be dealt with.

Please ask the Debian folks to file tickets against RubyGems, or to re-raise discussions on the rubygems-developers mailing list.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: