[Rubygems-developers] Deprecating gems
gsinclair at soyabean.com.au
Sun Apr 17 20:49:23 EDT 2005
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
> 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,
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
> 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.
More information about the Rubygems-developers