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

On 16 Sep 2010, at 06:44, Marcus Rueckert wrote:

> On 2010-09-16 03:36:56 +0900, James Cox wrote:
>> I don't believe the issue is as grave as you suggest. there's no
>> reason that stdlib needs to be at the same release version as ruby; =
it
>> just needs to be clear what the cutoff points are. However, if i am
>> wrong, the fix is simple: specify to each stdlib maintainer that they
>> are not at liberty to update release versions outside of ruby, other
>> than to specify patch level releases until the newer ruby is made.
>=20
> ok I thought a bit more about your idea ... and it is not going to =
work.
> lets say you force a library to a versioning scheme of 1.9.2.z. where
> they are only allowed to update the z part.
>=20
> now we currently have
> various 1.8.x
> 1.9.1
> 1.9.2
>=20
> do you want to force library authors to release a gem for each active
> branch to keep your versioning pattern?
>=20
> should we really end up with something like
> rubygems-1.8.7.1
> rubygems-1.9.1.2
> rubygems-1.9.2.2
>=20
> (just using rubygems as an example)
>=20
> the unified versioning idea doesnt make sense at all. and it doesnt =
even
> touch alternative ruby interpreter.

I agree, I think the important thing here is to talk about different =
aspects:

1. stdlib that is really part of the core ruby "kernel" set. Things like =
Time, Array extensions, Forwardable, weakref, resolv, rational, pp, etc.

2. "stdlib" that are really idempotent libraries like net/*, tmail, =
openssl, webrick, rdoc, etc.

The splits between these definitions could well lead to some discussion =
unto itself.

My point is, 1 needs to really remain very solidly stable. I would say =
that means we need to identify what is part of the language, and what is =
part of a library that's until now shipped with the language.

There are two problems here to executing these releases:

Firstly many of the items in (2) have had their backward compatibility =
removed by patches whilst they've lived in rubycore. Maybe this is =
purely an academic point, but the gems they're turned into must in the =
very least not get applied to old interpreters and then break peoples =
code.

Items in (1) are used so widely that we should really keep them as =
standard assets of the ruby interpreter library.

Rolling point releases of ruby to patch (1) for security should /not/ be =
a major issue, go into the last release branch if necessary, patch the =
one aspect, and roll a point release.

Rolling updates in the core gem bundles is a case of running a separate =
suite of tests to check that the bundled libs are ok. If there's a =
massive synchrony issue, then just drop the bundle. If we're doing sane =
versioning on both the Ruby and the library side, then a critical desync =
should never happen. If ruby breaks the API that a member of (2) uses in =
a point release, that's a fail of versioning, not a fail of (2) to be =
updated. (2) in the current version should /work/ on new point releases =
of ruby. This is a good measure for versioning guidance in fact. Updates =
of (2) should be pulled in for bundling on an acceptance basis, but =
generally that shouldn't lead to problems, if those bundled libs tests =
pass and example apps work as expected, we're good to go. That QA =
process is no different from normal.