[Rubygems-developers] Deprecating gems
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
>> 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
> rubyforge lists all gems that were /ever/ uploaded (minus the handfull
> 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
> 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
> 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
> archive versions and remove flawed gems on the server. Something like
> would allow the gem author to remove the deprecated gems themselves.
> 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