[Rubygems-developers] Deprecating gems

Chad Fowler chad at chadfowler.com
Sun Apr 17 18:55:00 EDT 2005

On 16-Apr-05, at 11:08 PM, Jim Weirich wrote:

> On Saturday 16 April 2005 09:33 pm, Gavin Sinclair wrote:
>> On the rails list, some confusion has permeated surrounding the wad of
>> gems surrounding sqlite.  The main problem is that one of them is
>> deprecated.
>> I suggested to Jamis that he update the description of the deprecated
>> one ("sqlite") which informs the user that it's deprecated and they
>> should use sqlite-ruby or sqlite3-ruby instead.
>> As far as I'm concerned, that's a sufficient solution.  Just thought
>> I'd mention the issue here, though, in case someone thinks an explicit
>> way of deprecating gems is a useful idea.
> I was actually thinking about such things recently.  Although its cool 
> that
> rubyforge lists all gems that were /ever/ uploaded (minus the handfull 
> that
> have been explicitly withdrawn), I'm wondering if that is a sustainable
> model. The yaml.Z file is enormous and most of those older gems that 
> have
> been replaced by newer versions are of little use to most people.
> Here's an  idea.  Establish some kind of policy on archiving older 
> versions of
> gems.  Hmmm ... something like keeping the last 10 version or the last 
> year's
> worth of versions (whichever is less) on the normal gem server
> (http://gems.rubyforge.org).  When a version falls off the map, move 
> it to
> http://gems.rubyforge.org/archive, where it will remain available.  If
> someone really needs it, they can use the --source option.  (the 10 
> version /
> 1 year criteria is offered as an example... feel free to debate the 
> merits of
> other policies).
> That will keep the main gem index from growing so large so fast.
> Beyond that, we should have an explicit interface for gem authors to 
> mark
> archive versions and remove flawed gems on the server.  Something like 
> this
> would allow the gem author to remove the deprecated gems themselves.  
> There
> would be some effort to put the interface together, but perhaps 
> someone would
> like to take it on as a RAILSDAY project :).
> Just some random thoughts on the topic.

I like these ideas.  I especially like the fact that --source could be 
used to access
archived gems.  The only thing I don't like about this is that it would 
remove the ability to
do a centralized search of every gem ever deployed.

Of course, that could be handled via a separate mechanism (like a web 

Someone on IRC suggested we deal with referrals at one point.  So, you 
could register just enough metadata to
respond to a search, but any request for details or the download of a 
gem would result in a referral (similar
to the way LDAP works, if any of you are familiar with it) which the 
gem client would follow.

Could be interesting.  Would require quite a bit of thought before 
implementing something like that.


More information about the Rubygems-developers mailing list