From: eregontp@... Date: 2018-07-14T11:18:27+00:00 Subject: [ruby-core:87943] [Ruby trunk Feature#5481] Gemifying Ruby standard library Issue #5481 has been updated by Eregon (Benoit Daloze). hsbt (Hiroshi SHIBATA) wrote: > You can commit it only github or MRI repo(SVN). Good to know, so contributing to the gem's GitHub repo or directly in MRI are both supported? > When you did commit code to github repo only, I merge them to MRI repo each week or month. > (The case of MRI to GitHub is same instructions.) > > I'm developing a merge tool between github and MRI repo [...] This sounds a bit similar to the synchronization with ruby/spec. For ruby/spec I preserve all history from downstream repos (MRI, JRuby, TruffleRuby) when importing to ruby/spec, and in the other direction I update specs as a single commit in downstream repos. Maybe https://github.com/ruby/mspec/blob/master/tool/sync/sync-rubyspec.rb can be useful as a base for your merge tool. Feel free to take any code from there, it's all written by me :) ---------------------------------------- Feature #5481: Gemifying Ruby standard library https://bugs.ruby-lang.org/issues/5481#change-72953 * Author: nahi (Hiroshi Nakamura) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Target version: ---------------------------------------- =begin Up-to-date summary of this proposal is at (()) == 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: