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

> If I understand the suggestion correctly...
>=20
> pros:
>  1) advantage for users: they can use "gem update" if stdlib has
>     an update.  Users can also use "gem remove".
>=20
>  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.=20

>  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=20

    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.