rubygems 1.8 is coming
Published 2011-05-04 @ 00:24
Rubygems 1.8 is about to be released soon and I wanted to take this opportunity to make a few remarks about it.
1) It is going to be noisy.
We’ve deprecated 22+ more methods in this release, some of which are written out to gemspecs. When they’re loaded back in, rubygems will bitch about the use of deprecated methods.
This is a good thing! By deprecating methods now, we can provide a better rubygems for you in the future.
Most noise coming from the specs themselves can be cleaned up very very easily with
gem pristine --all --no-extensions
You want that last flag so you skip over binary gems that might have needed manual compile flags to build.
Other gems, like
rake, are going to need to remove decrepit fields from their gemspecs and release a new version (which is a good thing! We’ve tried to get rake released for months now! :P).
Other gems, like rails, bundler, and other tools/libraries that directly tap into rubygems… Well, they’re going to have to adapt. We will remove deprecated methods on the dates given.. If a gem covers up a deprecation, swallows it, or otherwise obscures it, it’s doing all of its users a disservice. We’re not going to apologize if/when stuff breaks. We’re communicating loud and clear way ahead of time that stuff will break. It is time to move on from old bad code.
2) Stop being passive-aggressive.
- Number of whiny posts in blogs, stackoverflow, and twitter about rubygems 1.[4-7]: 34,164
- Number of bug reports filed against rubygems 1.[4-7]: 5.
If you see a problem with rubygems, tell us about it!. Don’t be a part of the problem! Be a part of the solution and help us make rubygems better.
Example: we saw a lot of passive whining that “rubygems broke rails” when in fact it was bundler’s method
cripple_rubygems that broke rails… It only looked like rubygems caused the problem. We got very very few people coming to talk to us about the problem.
Thanks to an extremely generous (and proactive) Evan Phoenix, there is no more
cripple_rubygems in bundler. There’s still lots of monkey patches in bundler but we’re working with Evan to get those phased out over time.
Addendum #1: Suggesting that you shouldn’t be passive-aggressive doesn’t equate to suggesting that you should be a dick about it.
3) Gem Tool Devs only: We’re disconnected from
Who should know where it’s gem directory is? The spec for the gem, aka:
Gem::Specification. Where should methods for searching through specs be?
We’ve deprecated all of
GemPathSearcher as they were just bad design through and through. Nearly everything has been absorbed into
Gem::Specification where it belonged.
What we’ve not done (consciously), is reworked SourceIndex to base it’s information off of Gem::Specification. We left it as untouched as possible in order to not drag us down with extra maintenance and cruft. As such, it is theoretically possible that SourceIndex and Specification might not think the same thing. Good. Switch to Specification and be happier.
4) There is more where that came from!
We’ve done a monthly release (+ bug fix releases) every month since new years eve, 2010 and we’re not slowing down anytime soon. While we’re not where we want it to be yet, we’re at least vectored in that direction now. Cruft is officially scheduled to be dropped. The design is moving in the right direction. The code is starting to feel right.
We’ve got more deprecations coming, better design in the works, and new features lined up, but we can always use more ideas from you. Please file feature requests with stuff you’d like to see.