[Rubygems-developers] 0.4.0 bugfix release

Gavin Sinclair gsinclair at soyabean.com.au
Mon May 31 10:48:23 EDT 2004

On Monday, May 31, 2004, 10:53:16 PM, Chad wrote:

> On 30/5/2004, at 6:06 PM, Jamis Buck wrote:

>> Chad Fowler wrote:
>>> FYI, Since we haven't seen a ton of activity recently on new  
>>> features, I'm going to release 0.4.0 quietly this evening just to get
>>> the newest, least-buggy code out for people to test/comment on.
>> Excellent!
>> What remains to be done for a 1.0 release? Is there a "to do" list
>> somewhere? I haven't contributed much yet to rubygems and I may have
>> some time in the near future that I could use for that.

> That would be great.  There is an incomplete TODO list here  
> http://rubyforge.org/cgi-bin/viewcvs/cgi/viewcvs.cgi/rubygems/TODO? 
> rev=1.12&cvsroot=rubygems&content-type=text/vnd.viewcvs-markup

> I think the following list would be nice:

> * syncing gem repositories

Let's get the notion of repositories sorted out first :)

> * finish removing STDIN/STDOUT dependencies in the lib

Yes, that's a curly one.

> * some kind of versioning change (mauricio, eivind, or jim's idea(s))
> should go into 0.5 for feedback/testing
> * optional dependencies: "semitar can use REXML, but it works better if
> you have the ruby raptor library installed",  or not so optional as in:
"you need Ruby/RSS >> = 1.0 OR rss > 0.91 for this library to work"

Hey, that's an interesting idea.  Never would have thought of that.
Although I guess it's slightly similar to "requirements" which seems
to be for information only.

> * ri data generation

This would be a fantastic thing to get working.  RubyGems seems
incomplete without it.  I think the best thing it to implement 'rig'
(ri gems) which is a wrapper around ri, and works something like this:

  rig --gem log4r           # shows all log4r classes
  rig --gem log4r to_s      # looks for to_s within log4r gem
  rig --all to_s            # looks for to_s within all gems
                            #   and in normal ri data

 * easy to implement
 * no change required to ri
 * gives us something that works and a platform to discuss future
   ri data generation

 * maybe not bold enough, or not the ultimate solution in everyone's

> * support for installing binary (pre-compiled), platform-dependent  
> gems.  This already works as long as you pick the right gem manaully,
> but I'd like the remote installer to intelligently select the right one
> and for the installer to throw an error (or a warning) if you attempt o
> install (e.g.) a Windows gem on a linux system.

Yeah, advancing this would be good.  How do you generate a binary gem?
Just like a normal one I suppose.  I don't think I've seen an example.

> * Allowing a gem to specify a required ruby version
> * Integration with platform-native packaging systems

Not being a common user of platform-native systems, I don't personally
care, and don't even see the point, but I know this has been on the
agenda since day one.


More information about the Rubygems-developers mailing list