[Rubygems-developers] 0.4.0 bugfix release
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.
>> 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
> 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