[Rubygems-developers] Deprecating gems
pabs at pablotron.org
Tue Apr 26 19:32:13 EDT 2005
* 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
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
Paul Duncan <pabs at pablotron.org> OpenPGP Key ID: 0x82C29562
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050426/4fcd8b2d/attachment.bin
More information about the Rubygems-developers