SlimGems, a drop-in replacement for RubyGems -- now available
gnuu.org
gnuu.org
* RubyGems now promises to stay API compatible with whatever version of gems ships with the latest point release of Ruby 1.9. That means if RubyGems 1.8 ships with Ruby 1.9.3, the RubyGems 1.8 API will be preserved at a minimum until Ruby 1.9.4 comes out, which will be no sooner than 6-18 months from now.
* RubyGems has removed two deprecation warnings in 1.8.4 and 1.8.5 that account for virtually all deprecation warnings that were frustrating users.
* Bundler works out of the box on RubyGems 1.8, as does Rails 3. The next point release of Rails 2.3 will also support RubyGems 1.8. Evan Phoenix is a maintainer of both RubyGems and Bundler, and is taking the responsibility of cutting stable releases of RubyGems for the time being, which nearly guarantees there will be no further Bundler issues.
* Frequent point releases of RubyGems should hopefully be a thing of the past, because starting with RubyGems 1.9, there will be beta and release candidates running for a month long cycle before they get shipped as stable releases that get installed by gem update --system
You can find additional information here: http://blog.majesticseacreature.com/tag/rubygems
Has anyone discussed emailing the authors specified in the gemspecs of the gems that will be breaking with these upcoming changes?
I was flabbergasted. Really? Nobody thought to check to make sure the package manager release doesn't break Rails 2 completely? I'm glad to see Loren and crew step up.
Rake is currently hosted at github. The github web page is http://github.com/jimweirich/rake/
In Rake 0.9.1 the global API is back, but with warnings this time.
The rake 0.9 beta was out for months, so I am surprised that something as high profile as rails got broken. While framework maintainers are ultimately responsible for their own stuff, the rake maintainer could have pro-actively made an announcement to the effect of "Hey, look out!"
In an ideal world, a continuous integration thingamabob would have sent an alert to rails maintainers about the breakage with the rake beta.
Strike my "0.8.7 to 0.9.0" rationale.
That would spoil the fun of make sweeping generalizations about thousands of people based on the behavior of a few.
You can recover some credibility if you can tell us specifically which minor upgrades caused breakage. You'll have to list a bunch of them in order to support the "regularly cause breakage" claim.
However I'm certain you won't be able to do that. Go troll somewhere else, please.
Essentially, what I mean to ask is if this kind of breakage is expected in JRuby anytime soon.
My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this case, it means even if RubyGems was called 2.0, you'd have the same technical problems if you have libs with dependencies on RubyGems 1.x and other libs with dependencies on RubyGems 2.x. Modules really should be used to namespace interfaces across major versions.
I agree that it doesn't necessarily mean that you won't have to rework your local code, but particularly with projects like RubyGems (which are more end-user than code integration points), it's more important to know whether or not upgrading will break your entire process.
As a concrete example, the redis-rb gem went to 2.0 and completely broke API compatibility. They did everything right by the semantic versioning book. I used about 10 libraries built atop redis-rb, but never used redis-rb directly. About half the libs updated and required the use of redis-rb 2.0, the other half did not. Moreover, the gem dropped protocol support for the old redis-server, too, so it forced a redis-server upgrade.
This was an absolute mess to work out because updating 10 libs at once is basically insane. And the whole thing could have been avoided if modules were used to namespace, allowing activation of both sets of classes.
But, anyway, this isn't to say semantic versioning has no value. It's just not a solution to a library that keeps changing its public API either.
(offtopic) Also, I too got bit by the redis-rb changes. They also broke apis from 2.1 => 2.2 as well. SemVer isn't hard, I don't understand why people can't follow it.
For critical infrastructure like package management, these kind of changes can be difficult to deal with. We're switching all of our projects to SlimGems, and are going to be contributing code for improving its use as a library for other software to build on.
Allow me to rewrite your statement to be ruby-drama-free:
We have been working on several JavaScript-related tools that build on top of RubyGems. As the most recent versions of RubyGems have begun deprecating standard APIs that we and many other projects rely on, we have decided to fork the project, with the intention of maintaining an alternative to RubyGems that maintains ongoing compatibility with the existing API.
<optional: insert rational for forking / discussion of how you would prefer to merge and not use the nuclear option of forking someone's project here>
I know this is mostly designed to be Internet Drama ("I've saved the Ruby community from the RubyGems Cowboys! Yay for me! I'm cooler than _why!!"), but the reality is, everyone wants their own package manager. Every Linux distribution has their own. Perl has three CPAN clients, two of which are in the core!
Anyway, I think this is supposed to be a Big Deal, but it's not.
"Deprecations would not mean warning messages or method removal. We will work with the community to make sure library developers upgrade their code on a convenient time frame for everybody (years, not months), and that nothing breaks. No rush!"
Then it's the kind of lesson that can be learned from and fixed. No need for forks.
http://blog.majesticseacreature.com/establishing-release-man...
I agree. But, to be fair, it's hard to hope for the project to be improved and fixed when someone responsibly brings up the issue on the RubyGems issue tracker and gets the following response from a RubyGems developer:
> Really? Don't you have anything better to do than to post inflammatory shit to this tracker?
No, that's not a great solution. But neither is supporting a fork by someone who's been working on this for three weeks when the current RubyGems core team has members on it with over 4 years of experience with the codebase. At the very least, this needs to stop being emotional and the technical points need to be laid out cleanly on white paper.
(Note: I read your message, know nothing of these people involved, and simply searched to find the issue as I wanted to actually see what had "gone down" for myself: that bug report, despite the fact that I don't even /use/ Ruby, "riled me up", which says something pretty bad about its intent.)