From: James Tucker <jftucker@...>
Date: 2010-09-16T23:58:42+09:00
Subject: [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.
> 
> 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.
> 
> now we currently have
> various 1.8.x
> 1.9.1
> 1.9.2
> 
> do you want to force library authors to release a gem for each active
> branch to keep your versioning pattern?
> 
> should we really end up with something like
> rubygems-1.8.7.1
> rubygems-1.9.1.2
> rubygems-1.9.2.2
> 
> (just using rubygems as an example)
> 
> 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.