[Rubygems-developers] Deprecating gems

[Gavin Sinclair]

On Monday, April 18, 2005, 8:55:00 AM, Chad wrote:

>> 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).

> 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.

That's probably not a search people want to do very much at all.  In
practice, I think deprecation of an entire gem (as opposed to archival
of old versions) would be rare.  It would be nice if gem could give
output like this:

  $ gem list -r rails

  rails (0.11.1, 0.11.0, 0.10.1, 0.10.0, ...)
      Web-application framework with template engine, control-flow layer,
      and ORM.

where the "..." is taken to mean "older versions available".

Having a separate gem server for archived gems is a good idea, I
believe, and the gem command could even recognise this:

  $ gem list -r rails --archive

  rails (0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0, 0.7.0, 0.6.5, 0.6.0)
      ...
      
> Of course, that could be handled via a separate mechanism (like a web
> app--hmmmm...).

:)

> 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.

Not familiar and don't quite understand, sorry.

Gavin