[Rubygems-developers] Deprecating gems

[Paul Duncan]

* Jim Weirich (jim at weirichhouse.org) 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.

What I'd also like is a way of sending deltas on the yaml.Z file.  For
example, a query of the remote list could send the last query date as an
HTTP header (HTTP 1.0 has "If-Modified-Since/Last-Modified", and HTTP
1.1 has "If-None-Match/ETag", which is an opaque value, but serves a
similar purpose), and the server could generate a response which
contains only the changes since that date.  Alternatively, RubyGems
could define it's own HTTP header ("X-RubyGems-Last-Update:" or
something comparably benign), or even pass the last updated timestamp as
a GET parameter.

It would also be nice to set up RubyGems mirrors -- I could spare
50-150G a month, and I'm sure we've got other people who could do the
same.

The combination of sending deltas and having a set of official mirrors
should significantly speed up remote operations in RubyGems.

> 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.
> 
> -- 
> -- 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)
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers

-- 
Paul Duncan <pabs at pablotron.org>        OpenPGP Key ID: 0x82C29562
http://www.pablotron.org/               http://www.paulduncan.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050426/4fcd8b2d/attachment.bin