From: Ryan Davis <ryand-ruby@...>
Date: 2010-09-09T13:53:03+09:00
Subject: [ruby-core:32216] Re: Can we convert the standard library to gems?


On Sep 8, 2010, at 10:06 , Yusuke ENDOH wrote:

> If I understand the suggestion correctly...
> 
> pros:
>  1) advantage for users: they can use "gem update" if stdlib has
>     an update.  Users can also use "gem remove".
> 
>  2) advantage for library developers: they can preserve separate
>     releases from Ruby itself.

I think it is still up to the library developers to do exactly what they're doing now: periodically updating ruby trunk with the latest blessed release of the library. This is no different whether we ship via gems or via source duplicated from another VCS. 

>  3) advantage for the core team: they not have to do security
>     release if stdlib has a security issue, because "gem update"
>     can be used.

I think FreeBSD + ports is a good model here. I see it as 

    ruby + core libs : ruby stdlib :: freebsd distro : freebsd ports

When a security announcement is released for freebsd itself, they usually provide a workaround + patch that you can apply immediately and then you can follow up with an official update. When a security announcement is released for a port, you can update the ports tree and update that port independent of a freebsd release.

It is more granular and provides a lot more flexibility and responsiveness.

> 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.