[ruby-core:32273] Re: Can we convert the standard library to gems?

2010/9/10 Ryan Davis <[e-mail]>:
>
> On Sep 9, 2010, at 06:40 , Yusuke ENDOH wrote:
>
>> 2010/9/9 Ryan Davis <[e-mail]>:
>>>> cons:
>>>> 1) disadvantage for the core team: developping style will get
>>>> omplex. he core team must care multiple entities: Ruby
>>>> ackage and stdlib gems.
>>>
>>> I can see that if ruby is viewed (using the analogy above) as the whole
>>> freebsd distro, but I don't think that view is necessarily valid. For
>>> example, why must webrick require a full release cycle (and version
>>> number--we still have that problem) when it can be addressed with an
>>> announcement saying "security problem. run gem update webrick to fix it"?
>>>
>>> Certainly we'd want future releases of ruby to update the supplied webrick,
>>> but I don't think it necessitates a full release, esp if the user is
>>> immediately encouraged to update rubygems + installed gems at ruby install
>>> time.
>>
>> I insisted the completely same thing to committers.
>> If we don't have to do full release when security issue is reported,
>> it is definitely an advantage for the core team.
>> But, Urabe san said, full release is needed even if "gem update"
>> can be used.
>
> Then we need to change Urabe's mind. I think his argument does more harm than good by delaying fixes in order to coordinate full releases. If ruby+gem installs do an automated update at the end of install, then there is NO reason why security fixes should be delayed for full releases.

Before this, some concreate and overall plan is needed.

I still don't know how the change is applied and how we work after this.

-- 
NARUSE, Yui
[e-mail]