On Sep 9, 2010, at 06:40 , Yusuke ENDOH wrote:

> 2010/9/9 Ryan Davis <ryand-ruby / zenspider.com>:
>>> cons:
>>> 1) disadvantage for the core team: developping style will get
>>>    complex.  The core team must care multiple entities: Ruby
>>>    package 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.