From: Eric Hodel Date: 2011-10-25T13:40:59+09:00 Subject: [ruby-core:40329] Re: [ruby-trunk - Feature #5481] Gemifying Ruby standard library On Oct 24, 2011, at 8:49 PM, Yusuke Endoh wrote: > Hello, > > Could you summarize advantages (if any) and disadvantages > (or additional work) from POV of each person? I will describe my thoughts > - user Users can obtain improvements to parts of ruby without waiting for a new release. No need to `gem 'rdoc'`, `gem 'psych'`, etc. to use the latest installed version of a gem. With the current implementation default gems are special. This proposal will make them stop being special. > - default gem developer Default gem developers won't have to educate users to do something special to use the latest version of the library. Default gem developers may need to support multiple versions of ruby in their gem or backport one fix to multiple releases (like backport requests to Ruby 1.9.3 and Ruby 1.9.2). Default gem developers can release improvements between ruby release cycles. > - rubygems developer We may need to implement better RubyGems platform support, but the idea is applicable beyond just improving stdlib gems. > - rubygems.org admin The rubygems.org admin should not need to do anything special. > - ruby committer <= I'm personally concerned about these This proposal leaves the organization of the standard library the same. There will be changes in tool/ to support turning parts of stdlib into gems when `make install` is run, but most committers will not need to care. > - ruby release manager <= The release manager will need to upload gems to rubygems.org when releases are made. This process can be fully automated. > - ruby security team <= I don't think I'm qualified to answer this one.