[ruby-core:96426] [Ruby master Feature#5481] Gemifying Ruby standard library

Issue #5481 has been updated by hsbt (Hiroshi SHIBATA).


@marcandre

You can pick the commits from ruby/* repository like this.

```
# git clone from the upstream repository and copy from the upstream repository with cp -rf. It's lost the git commits.
ruby tool/sync_default_gems.rb rubygems
# pick the single commit from the upstream repository.
ruby tool/sync_default_gems.rb rubygems 97e97686123e7338db628377d2f01516c8f9738f
# pick the commits range from the upstream repository
ruby tool/sync_default_gems.rb rubygems 97e97686123e7338db628377d2f01516c8f9738f..9e53702832
```

Sorry, your inconvenience experience. So, there is no enough document about default gems maintenance. I will prepare that in the next year.

----------------------------------------
Feature #5481: Gemifying Ruby standard library
https://bugs.ruby-lang.org/issues/5481#change-83348

* Author: nahi (Hiroshi Nakamura)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* Target version: 
----------------------------------------
=begin

Up-to-date summary of this proposal is at ((<URL:https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem>))

== Motivation

 * ruby's release cycle is slow for some standard libraries;
   * ex. security fix for WEBrick, xmlrpc and Zlib.
   * ex. API iteration for net/http, OpenSSL, json, psych, RDoc, minitest and rake.
 * There's already the feature called 'default gems' in ruby and some stdlibs are already using it:
   * rake, rdoc, minitest, json, io-console, bigdecimal
   * And some gems are already doing out-of-band releases.
 * When releasing we should give independence equally to all stdlibs, but in a consistent and controllable way.

== Proposal

 * Allow out-of-band stdlib releases.
   * We are not proposing changes to ruby's release management, the release manager would decide when they release ruby and stdlib.
 * Allow more stdlibs to be installed as a 'default gem'
 * Register these gems on RubyGems.org
   * Introduce a new mechanism: controlling supported ruby version so that we can avoid installing unexpected version of stdlib gems.
     For example, a WEBrick gem for ruby 2.0.1 (released from ruby_2_0_1 branch) should not be installed for ruby 2.0.0 (released from ruby_2_0_0 branch) unless we know it works for both 2.0.0 and 2.0.1.

Note:

 * Moving stdlibs repository location is not a target of this proposal. The implementation details of stdlib gems should hide this from ruby committers.
 * ruby_1_9_3 is not a target of this proposal. The change should be introduced from 2.0.0 release.


...Some more details of the proposal and discussion topics are going to follow as comments.
=end


---Files--------------------------------
5481.pdf (78.2 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>