[Rubygems-developers] Specifying equivalent modules?

Jim Weirich jim.weirich at gmail.com
Thu Apr 19 22:08:46 EDT 2007


On 4/19/07, Charles Oliver Nutter <charles.nutter at sun.com> wrote:
> Eric Hodel wrote:
> > On Apr 18, 2007, at 20:43, Charles Oliver Nutter wrote:
> >> Eric Hodel wrote:
> >>> On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote:
> >> which means that Zed, who 'owns' the "mongrel" gem name, would have to
> >> be responsible for publishing a Java platform gem.

Actually, no.  See below.

> However to have to expect each and every author of a native module to do
> all this is silly. They shouldn't have to do it, and we shouldn't expect
> them to do it. But if jmongrel or anything else is functionally
> equivalent to mongrel under JRuby (and in truth, the only way someone
> running JRuby can run mongrel), there should be a simple way to fit
> jmongrel into the family without having to hassle Zed or anyone else.

Zed would not have to be "responsible" for releasing a java platform
mongrel gem.  Someone else could do all the work and even handle the
release.  The only coordination that would be required is that for a
given version number, the C platform and the Java platform gems have
compatible APIs.  The two platforms would require some level of
compatiblity anyways, otherwise plain ruby software would not be able
to run on the other.  The reason for the version alignment is so that
if my software requires version 1.2 of mongrel, it means the same
thing in both MRI and JRuby land.

On version alignment, the two platforms wouldn't even to be *exactly*
aligned.  Generally (if used properly in the Gem world), only the
first two numbers of a version denote features.  The third (and beyond
third) number in the version generally denotes build revisions.  So,
if mongrel-C and mongrel-JRuby keep feature aligned on the first two
numbers in a version, i suspect that would be adequate.

The only other (minor) problem I see is that currently RubyForge
requires that a Gem come from a single RubyForge project.  I suspect
we can convince the RubyForge guys to allow different platform gems to
come from different projects.

-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)


More information about the Rubygems-developers mailing list